В рубрику "Центры обработки данных (ЦОД)" | К списку рубрик | К списку авторов | К списку публикаций
Но граница системы – это не то место, где удобно поставить защиту, а то место, где возможен переход этой самой границы. А этот переход с существенно большей вероятностью возможен через рабочие места пользователей, чем через сервера ЦОД, находящиеся в тщательно контролируемой зоне. Однако компьютеры пользователей так далеко от ЦОД, что необходимость их защиты не кажется очевидной.
Однако для безопасности всей системы целиком, со всеми ее владельцами и пользователями, нет никакой разницы, что именно не защищено – ЦОД или компьютер клиента: защищенность системы равна защищенности ее самого слабого звена.
Необходимо обеспечить корректность функционирования ПО на клиентском компьютере: оно должно правильно подключиться к нужному облаку, корректно визуализировать получаемые из облачной инфраструктуры данные, правильно обрабатывать вводимые пользователем данные и сохранять результат именно в том облаке, в котором необходимо. Сбой на любом из перечисленных выше этапов может привести к утечкам пользовательских данных, даже несмотря на то, что облако защищено в центре. На компьютерах пользователей должна быть создана доверенная среда.
Самым простым и надежным средством для этого является аппаратный модуль доверенной загрузки (АМДЗ). АМДЗ широко применяется в корпоративной среде, и его также можно применять в облачной инфраструктуре.
Необходимость применения АМДЗ глубоко проработана в научных трудах, например [1, 2], и подтверждается давней практикой применения. Настолько глубоко и давно, что ФСТЭК разработал и выпустил отдельный документ, посвященный требованиям к СДЗ [3]. В этом документе подробно рассматриваются их типы, выделяются классы защиты, специфицируются профили защиты СДЗ. При всем многообразии и различиях их объединяет одно общее свойство – считается, что они должны быть постоянно установлены в защищаемые компьютеры.
Это входит в противоречие с двумя очень существенными свойствами облачной инфраструктуры:
Проблему можно решать в двух направлениях:
Каким именно способом целесообразно создавать доверенную среду на клиентском компьютере, в первую очередь зависит, конечно, от того, что это за клиентский компьютер. А это, в свою очередь, определяется тем, какой сценарий работы актуален для эксплуатирующей облако организации или для конкретного пользователя.
Этот вариант делится на два: пользователь должен работать с использованием ресурсов тех компьютеров, которые определены его рабочими местами, или без использования этих ресурсов.
1) В первом случае, если нет возможности применения привычных видов СДЗ, можно рассмотреть вариант использования АМДЗ, выполненного в форм-факторе USB-устройства. Функционально такой АМДЗ полностью аналогичен устройству, выполненному в виде платы расширения. То есть он выполняет контроль целостности аппаратуры, контроль целостности файлов и реестра, производит аппаратную идентификацию пользователя. Этого функционала достаточно для полноценной работы в качестве АМДЗ.
2) Терминалы и примкнувшие к ним zero-клиенты действительно содержат ОС в минимальном составе, ряд утилит по настройке и ПО, обеспечивающее подключение к терминальному серверу или виртуальному рабочему столу. На подобных рабочих местах действительно не хранятся пользовательские данные. Но доверенная загрузка необходима и в этом случае, ведь и в минимальную по размеру ОС может быть внедрена закладка.
Для таких сценариев оптимальны комплексы защищенного хранения и сетевой загрузки ОС терминальных станций.
Универсальная часть образа ОС клиентского терминала при этом загружается с отчуждаемого персонального устройства пользователя, а затем со специального сервера хранения и сетевой загрузки на клиент скачивается и после успешной проверки целостности и аутентичности загружается та его часть, которая требует администрирования. Эта часть образа включает средства поддержки периферии (она может выходить из строя или просто заменяться), ограничения доступа к устройствам ввода-вывода и съемным носителям (принтерам, флешкам), клиент VPN и тому подобные "индивидуальные" настройки. Она должна быть доступной для изменений, но в то же время верифицируемой. Это и обеспечивается комплексами защищенного хранения и сетевой загрузки, которые помимо персональных загрузочных устройств и сервера хранения и сетевой загрузки включают в себя АРМ для конструирования загружаемых образов ОС.
Чтобы обеспечивать комфортное применение и администрирование, такой комплекс должен включать в себя средства сопоставления загружаемых образов, загрузочных устройств и пользователей между собой, а также быть интегрированным со средствами защиты ЦОД. А чтобы обеспечивать необходимый уровень защищенности, комплекс должен иметь механизмы контроля целостности и аутентичности загружаемых образов.
Для таких случаев идеально подходят средства обеспечения доверенного сеанса связи (СОДС). СОДС позволяет расширить границы мобильности далеко за пределы офиса за счет изменения логики контроля неизменности программного обеспечения и соответствия его эталону. Суть решения СОДС состоит в том, что пользователь носит с собой не средство контроля целостности среды, а саму среду в недоступном для изменения виде. У пользователя есть устройство с интерфейсом USB размером со стандартную флешку, по сути своей являющееся именно флешкой, но имеющей ряд особенностей. Во-первых, с этого устройства можно загружать компьютер. Во-вторых, операционная система, которая будет загружаться на компьютере, хранится на диске в режиме "только для чтения". В-третьих, в этой операционной системе предустановлено все необходимое программное обеспечение для доступа к облачной инфраструктуре, как на прикладном, так и системном уровне. Таким образом, корпоративные пользователи облачной инфраструктуры могут с любого компьютера, в том числе – планшетного, работать с облаком из доверенной среды. При этом СОДС может быть идентификатором пользователя в средствах защиты ЦОД, а в состав загружаемой ОС может входить VPN-клиент, сервер которого – в ЦОД.
Единственная особенность, которую необходимо иметь в виду, – в отличие от описанных выше комплексов защищенного хранения и сетевой загрузки ОС терминальных станций СОДС не предоставляет возможности эксплуатирующей организации самостоятельно создавать или редактировать образы записанного в его защищенную память ОС. Поэтому при заказе устройств необходимо ясно понимать, что потребуется от устройства, и четко сформулировать заказ.
Для этого необходимо перенести в мобильное устройство последнее, что осталось, – сам компьютер.
Защищенная ОС в таком компьютере будет располагаться в банке памяти, физически переведенном в режим RO.
Нельзя не учитывать, что помимо защищенной работы с облаком пользователю хотелось бы иметь и обычные возможности незащищенной работы, например в Интернете. Из доверенной среды нельзя выходить в незащищенный Интернет, так как в результате доверенность может быть нарушена.
Наилучшее разрешение этого противоречия – наличие еще одной ОС, незащищенной, без ограничений по доступу в Интернет. Носителем этой ОС может быть еще один банк памяти с полным доступом.
Выбор той из двух ОС, которая должна быть загружена в каждом конкретном случае, должен осуществляться: а) пользователем; б) с помощью физического, а не программного воздействия (потому что только таким образом можно гарантировать, что это переключение не может осуществить злоумышленник с помощью программной атаки). Для этого на корпусе устройства должен быть переключатель.
Условия сохранения доверенности защищенной ОС обеспечиваются тем, что разные ОС не имеют общего информационного ресурса. Взаимовлияние защищенной и незащищенной ОС друг на друга исключено, так как они размещены в физически разделенных банках памяти и ни при каких обстоятельствах не могут быть запущены одновременно.
Такое решение получено, и оно защищено патентами с 16 патентными формулами. Основанные на этом решении компьютеры выпускаются в виде планшетов, в форм-факторе большой флешки, в виде телефона и в форм-факторе отчуждаемого активного блока и док-станции. Телефон и терминал с док-станцией – стационарные решения, планшеты же и устройства в виде большой флешки – это мобильные устройства, носимые с собой.
Так что получается, что никаких особенных сложностей в обеспечении ИБ в ЦОД нет.
Литература
Опубликовано: Журнал "Information Security/ Информационная безопасность" #6, 2014