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

Сложности обеспечения ИБ в ЦОД

Сложности обеспечения ИБ в ЦОД

В рубрику "Центры обработки данных (ЦОД)" | К списку рубрик  |  К списку авторов  |  К списку публикаций

Сложности обеспечения ИБ в ЦОД

Сложность обеспечения ИБ в ЦОД состоит только в одном – верном определении границы защищаемой системы. Казалось бы, что тут определять: если обеспечиваем ИБ в ЦОД, то защищаемая система – это ЦОД и есть. И действительно, редко подвергается сомнению, что на серверах облачной инфраструктуры, на оборудовании ЦОД должны применяться средства доверенной загрузки (СДЗ).
Дмитрий
Счастный
Заместитель генерального директора “ОКБ САПР"
Светлана
Конявская
Заместитель генерального директора “ОКБ САПР"

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

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

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

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

Создаем доверенную среду

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

Необходимость применения АМДЗ глубоко проработана в научных трудах, например [1, 2], и подтверждается давней практикой применения. Настолько глубоко и давно, что ФСТЭК разработал и выпустил отдельный документ, посвященный требованиям к СДЗ [3]. В этом документе подробно рассматриваются их типы, выделяются классы защиты, специфицируются профили защиты СДЗ. При всем многообразии и различиях их объединяет одно общее свойство – считается, что они должны быть постоянно установлены в защищаемые компьютеры.

Это входит в противоречие с двумя очень существенными свойствами облачной инфраструктуры:

  1. возможность использования в качестве клиентского устройства практически чего угодно;
  2. доступ к своей персональной информационной среде откуда угодно, мобильность рабочего места вместо привязанности к своему рабочему кабинету.

Проблему можно решать в двух направлениях:

  1. использовать всегда только те компьютеры, для которых есть широко известные средства защиты, установив стационарные СДЗ на все компьютеры в мире (любой разработчик стационарных СДЗ поддержит этот способ);
  2. использовать мобильные СДЗ или клиентские компьютеры с защищенной архитектурой.

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

Пользователь работает с ЦОД с ограниченного круга компьютеров и/или ноутбуков, расположенных в разных местах

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

1) В первом случае, если нет возможности применения привычных видов СДЗ, можно рассмотреть вариант использования АМДЗ, выполненного в форм-факторе USB-устройства. Функционально такой АМДЗ полностью аналогичен устройству, выполненному в виде платы расширения. То есть он выполняет контроль целостности аппаратуры, контроль целостности файлов и реестра, производит аппаратную идентификацию пользователя. Этого функционала достаточно для полноценной работы в качестве АМДЗ.

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

Для таких сценариев оптимальны комплексы защищенного хранения и сетевой загрузки ОС терминальных станций.

Универсальная часть образа ОС клиентского терминала при этом загружается с отчуждаемого персонального устройства пользователя, а затем со специального сервера хранения и сетевой загрузки на клиент скачивается и после успешной проверки целостности и аутентичности загружается та его часть, которая требует администрирования. Эта часть образа включает средства поддержки периферии (она может выходить из строя или просто заменяться), ограничения доступа к устройствам ввода-вывода и съемным носителям (принтерам, флешкам), клиент VPN и тому подобные "индивидуальные" настройки. Она должна быть доступной для изменений, но в то же время верифицируемой. Это и обеспечивается комплексами защищенного хранения и сетевой загрузки, которые помимо персональных загрузочных устройств и сервера хранения и сетевой загрузки включают в себя АРМ для конструирования загружаемых образов ОС.

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

Пользователь работает с ЦОД с произвольного компьютера

Для таких случаев идеально подходят средства обеспечения доверенного сеанса связи (СОДС). СОДС позволяет расширить границы мобильности далеко за пределы офиса за счет изменения логики контроля неизменности программного обеспечения и соответствия его эталону. Суть решения СОДС состоит в том, что пользователь носит с собой не средство контроля целостности среды, а саму среду в недоступном для изменения виде. У пользователя есть устройство с интерфейсом USB размером со стандартную флешку, по сути своей являющееся именно флешкой, но имеющей ряд особенностей. Во-первых, с этого устройства можно загружать компьютер. Во-вторых, операционная система, которая будет загружаться на компьютере, хранится на диске в режиме "только для чтения". В-третьих, в этой операционной системе предустановлено все необходимое программное обеспечение для доступа к облачной инфраструктуре, как на прикладном, так и системном уровне. Таким образом, корпоративные пользователи облачной инфраструктуры могут с любого компьютера, в том числе – планшетного, работать с облаком из доверенной среды. При этом СОДС может быть идентификатором пользователя в средствах защиты ЦОД, а в состав загружаемой ОС может входить VPN-клиент, сервер которого – в ЦОД.

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

Пользователь должен работать с ЦОД даже в том случае, если компьютера нет совсем (а есть только телевизор или, например, проектор)

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

Защищенная ОС в таком компьютере будет располагаться в банке памяти, физически переведенном в режим RO.

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

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

Наилучшее разрешение этого противоречия – наличие еще одной ОС, незащищенной, без ограничений по доступу в Интернет. Носителем этой ОС может быть еще один банк памяти с полным доступом.

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

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

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

Так что получается, что никаких особенных сложностей в обеспечении ИБ в ЦОД нет.

Литература

  1. Конявский В.А. Управление защитой информации на базе СЗИ НСД "Аккорд". – М.: Радио и связь, 1999. – 325 с.
  2. Конявский В.А., Гадасин В.А. Основы понимания феномена электронного обмена информацией. – Минск: Серия "Библиотека журнала "УЗИ", 2004. – 327 c.
  3. Требования к средствам доверенной загрузки, утвержденные приказом ФСТЭК России от 27 сентября 2013 г. – № 119 (зарегистрирован Минюстом России 16 декабря 2013 г., рег. № 30604).

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

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

Дмитрий

Дмитрий  Счастный

Начальник отдела разработки и проектирования ТС СЗИ, ОКБ, "САПР"

Всего статей:  3

  Автор

Светлана

Светлана  Конявская

кандидат филологических наук, ЗАО "ОКБ САПР"

Всего статей:  45

В рубрику "Центры обработки данных (ЦОД)" | К списку рубрик  |  К списку авторов  |  К списку публикаций