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

Специфика угроз ИБ и защита от них в ЦОД

Специфика угроз ИБ и защита от них в ЦОД

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

Специфика угроз ИБ и защита от них в ЦОД

Чтобы получить в ЦОД в свое распоряжение виртуальные машины (ВМ), нужно определить, какими именно ресурсами эта машина должна располагать, и попросить администратора создать именно такую ВМ. Однажды созданная, она останется именно такой до тех пор, пока не будет изменена или удалена администратором. Другими словами, мы наблюдаем статическое распределение ресурсов. Пользователь знает, где именно находится его ВМ и что она собой представляет.
Валерий
Конявский
Научный руководитель ВНИИПВТИ, научный консультант ОКБ САПР, д.т.н.
Дмитрий
Угаров
Разработчик прикладного ПО ЗАО “ОКБ САПР"

Несколько ЦОД иногда объединяются одним механизмом управления. Теперь ВМ могут размещаться не только на разных физических серверах, но и в разных ЦОД. Но до сих пор пользователь при желании может точно установить, где находится его конкретная виртуальная машина.

Так может продолжаться до тех пор, пока ресурсов группы ЦОД хватает для размещения всех требуемых виртуальных машин. Рано или поздно все ресурсы окажутся занятыми, и тогда придется "уплотняться". Мало кто удержится от заказа ВМ "на вырост". Конечно, за заказанные ресурсы нужно платить, но не так уж и много, и значит лучше взять "про запас". В результате, хотя эффективность использования ресурсов в ЦОД намного выше, чем при использовании ПЭВМ, все-таки оптимальным такое использование не назовешь. Каждый взял себе по 20–30% запаса ресурсов, значит свободные ресурсы есть, а использовать их нельзя. Неэкономно получается. Тогда появляется потребность в динамическом распределении (выделении) ресурсов – это то, что отличает облако.

Защищенность ЦОД складывается из нескольких компонентов: защищенные серверы, инфраструктура виртуализации, ВМ и доступ (Web и/или терминальный).

Пошаговый контроль

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


В свою очередь, для того чтобы получить возможность работать внутри ВМ, нужно произвести следующие шаги:

• включение физических серверов – загрузка основных ОС (ОС гипервизора/ОС с управляющими сервисами) – включение управляющих сервисов – посыл сигнала о включении ВМ – обработка сигнала гипервизором – включение ВМ – загрузка ОС.

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

Защищенность ЦОД не имеет смысла, если взаимодействующие с ним пользователи работают в недоверенной среде.

В этом смысле необходимо учитывать два обстоятельства:

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

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

  1. фиксированные рабочие места пользователей, контролируемые (управляемые) службой ИБ (относится она к владельцу ЦОД или нет – вопрос в данном случае второстепенный; достаточно знать, что какой-то службой ИБ контролируется):
    • ПЭВМ;
    • тонкие клиенты;
  2. неизвестный и неконтролируемый парк СВТ.

Неизвестный и неконтролируемый парк СВТ

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

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

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

  1. Перед загрузкой сервера виртуализации должна обеспечиваться целостность:
    • оборудования сервера;
    • BIOS сервера;
    • файлов гипервизора;
    • установленных на гипервизор средств защиты.
  2. В виртуальных машинах должна контролироваться целостность:
    • статических файлов ВМ;
    • файлов гостевых ОС;
    • установленных в гостевой ОС средств защиты.
  3. В серверах управления должна контролироваться целостность:
    • оборудования сервера/BIOS сервера;
    • файлов ОС;
    • файлов системы управления инфраструктурой виртуализации;
    • установленных в ОС средств защиты.

Целостность машин с дополнительными службами инфраструктуры виртуализации должна обеспечиваться аналогично виртуальным машинам, если они установлены на ВМ, и аналогично серверам управления, если они установлены на физические серверы.

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

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


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

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

Фиксированные рабочие места, контролируемые службой ИБ

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

Рабочие места в общем случае можно разделить на ПЭВМ и тонкие клиенты.

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

ПЭВМ почти наверняка используются не только для взаимодействия с ЦОД, но и автономно. И значит, они должны быть защищены полноценным программно-аппаратным комплексом СЗИ НСД (например, "Аккорд-Win32" или "Аккорд-Win64"). В зависимости от политики безопасности запуск ВМ может требовать от пользователя, например, предъявления другого идентификатора.

Важно понимать, что, даже если единственной задачей пользователя ПЭВМ является работа с виртуальной инфраструктурой, все равно необходима установка именно ПАК, ограничиваться только АМДЗ неверно, так как, даже если пользователь не должен, он может использовать ОС своего компьютера для каких-либо неустановленных задач и контролировать потенциально общий ресурс необходимо.

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

При этом с точки зрения действий пользователей система практически не будет отличаться, с одной стороны, от построенной на базе СОДС, а с другой – от реальной терминальной системы: пользователь будет подключать USB-устройство, вводить PIN-код и ожидать загрузки терминала и старта сессии с терминальным сервером. О том, что он виртуальный, пользователь может и вовсе не знать. В рамках сессии то же USB-устройство выполняет функцию идентификатора пользователя в ПАК СЗИ НСД на серверной части системы.

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

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

Валерий Конявский

Валерий Конявский

Директор ВНИИПВТИ, доктор технических наук

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

  Автор

Дмитрий Угаров

Дмитрий Угаров

Разработчик прикладного ПО ЗАО “ОКБ САПР"

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

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