В рубрику "Центры обработки данных (ЦОД)" | К списку рубрик | К списку авторов | К списку публикаций
Несколько ЦОД иногда объединяются одним механизмом управления. Теперь ВМ могут размещаться не только на разных физических серверах, но и в разных ЦОД. Но до сих пор пользователь при желании может точно установить, где находится его конкретная виртуальная машина.
Так может продолжаться до тех пор, пока ресурсов группы ЦОД хватает для размещения всех требуемых виртуальных машин. Рано или поздно все ресурсы окажутся занятыми, и тогда придется "уплотняться". Мало кто удержится от заказа ВМ "на вырост". Конечно, за заказанные ресурсы нужно платить, но не так уж и много, и значит лучше взять "про запас". В результате, хотя эффективность использования ресурсов в ЦОД намного выше, чем при использовании ПЭВМ, все-таки оптимальным такое использование не назовешь. Каждый взял себе по 20–30% запаса ресурсов, значит свободные ресурсы есть, а использовать их нельзя. Неэкономно получается. Тогда появляется потребность в динамическом распределении (выделении) ресурсов – это то, что отличает облако.
Защищенность ЦОД складывается из нескольких компонентов: защищенные серверы, инфраструктура виртуализации, ВМ и доступ (Web и/или терминальный).
Для невиртуализованных систем загрузку и работу в доверенной среде позволяют производить комплексы, состоящие из взаимодействующих между собой аппаратного модуля доверенной загрузки и ПО разграничения доступа, контролирующих: включение СВТ – загрузку неизмененной ОС – разграничение доступа в ОС. Основой этих комплексов является принцип пошагового контроля (для контроля данных на i-м логическом уровне их представления требуется использование предварительно проверенных на целостность процедур (i-1)-го уровня).
В свою очередь, для того чтобы получить возможность работать внутри ВМ, нужно произвести следующие шаги:
• включение физических серверов – загрузка основных ОС (ОС гипервизора/ОС с управляющими сервисами) – включение управляющих сервисов – посыл сигнала о включении ВМ – обработка сигнала гипервизором – включение ВМ – загрузка ОС.
Очевидно, что в этом случае использование комплекса, предназначенного для физической инфраструктуры, недостаточно: не будет сохранен принцип пошагового контроля – целостность включаемой ВМ не будет проверена.
Защищенность ЦОД не имеет смысла, если взаимодействующие с ним пользователи работают в недоверенной среде.
В этом смысле необходимо учитывать два обстоятельства:
Легко заметить, что эти вопросы находятся в иерархической связи и дают следующие варианты систем:
Казалось бы, этот случай полностью исключает возможность гарантировать защищенность. И если ЦОД может доказать свою безопасность для использующих его клиентов подтверждением своей защищенности теми или иными средствами, аттестатом соответствия и т.д., то рассчитывать на такое же подтверждение со стороны пользователей, конечно, невозможно.
При этом такой незащищенный клиент подвергает опасности не только себя (считая, что он защищен, раз облако защищенное), но и сам ЦОД, создавая "дыру в заборе".
В инфраструктуре виртуализации должна обеспечиваться целостность программной среды на всех уровнях, а также целостность всех модулей защиты.
Целостность машин с дополнительными службами инфраструктуры виртуализации должна обеспечиваться аналогично виртуальным машинам, если они установлены на ВМ, и аналогично серверам управления, если они установлены на физические серверы.
Для доверия ЦОД пользователю необходим механизм контроля его вычислительной среды, что невозможно ни при каких других обстоятельствах, кроме применения технологии доверенного сеанса связи (ДСС) и средств его обеспечения (СОДС).
Принципиально важно, чтобы средство защиты ЦОД могло контролировать, действительно ли клиент подключился из доверенной среды!
Не всегда у пользователя под рукой оказывается одинаковый набор условий, но и не всегда ему нужен одинаковый набор услуг. Очевидно, что нельзя обеспечить безопасность любого сервиса на любом типе устройств в любое время в любом месте. Естественно ожидать, что в предоставлении части сервисов для некоторых устройств может быть отказано.
Отказ может последовать и в случае совокупности нетехнических факторов. Например, нахождение корпоративного абонентского устройства за пределами корпоративной беспроводной или проводной сети. А может и не последовать, если устройство при этом поддерживает работу в доверенном сеансе связи с необходимыми характеристиками.
Этот случай проще потому, что на состояние клиентских рабочих мест проще влиять: средства защиты, предписанные проектной документацией на систему, будут установлены на рабочие места пользователей.
Рабочие места в общем случае можно разделить на ПЭВМ и тонкие клиенты.
ПЭВМ почти наверняка используются не только для взаимодействия с ЦОД, но и автономно. И значит, они должны быть защищены полноценным программно-аппаратным комплексом СЗИ НСД (например, "Аккорд-Win32" или "Аккорд-Win64"). В зависимости от политики безопасности запуск ВМ может требовать от пользователя, например, предъявления другого идентификатора.
Важно понимать, что, даже если единственной задачей пользователя ПЭВМ является работа с виртуальной инфраструктурой, все равно необходима установка именно ПАК, ограничиваться только АМДЗ неверно, так как, даже если пользователь не должен, он может использовать ОС своего компьютера для каких-либо неустановленных задач и контролировать потенциально общий ресурс необходимо.
Применение тонких клиентов, как правило, связано с тем, что локально задачи пользователями не выполняются или они минимальны. В то же время ОС тонких клиентов тоже должна быть доверенной. И в этом случае целесообразно применять либо СОДС, либо – если пользователи работают в терминальном режиме с виртуальным терминальным сервером – ПАК для защищенной сетевой загрузки ОС терминальных клиентов (например, КАМИ-терминал или "Центр-Т"), обеспечивающий защищенное хранение и доверенную сетевую загрузку образов ПО терминальных станций с подтверждением их целостности и аутентичности.
При этом с точки зрения действий пользователей система практически не будет отличаться, с одной стороны, от построенной на базе СОДС, а с другой – от реальной терминальной системы: пользователь будет подключать USB-устройство, вводить PIN-код и ожидать загрузки терминала и старта сессии с терминальным сервером. О том, что он виртуальный, пользователь может и вовсе не знать. В рамках сессии то же USB-устройство выполняет функцию идентификатора пользователя в ПАК СЗИ НСД на серверной части системы.
Опубликовано: Журнал "Information Security/ Информационная безопасность" #6, 2013