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

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

Научный руководитель ВНИИПВТИ, научный консультант ОКБ САПР, д.т.н.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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