Очевидно, что в общем случае ни мы не доверяем облаку, ни облако не доверяет нам. Что бы у нас были основания доверять облаку, его владелец должен предпринять серьезные усилия по защите ЦОДов. Чтобы облако доверяло нам – мы должны, как минимум, обеспечить доверенную среду на своих компьютерах.
Контролируемый старт системы виртуализации, защита ВМ
ЦОДы могут быть с виртуализацией на базе VMware или на базе Hyper-V.
Рассмотрим защиту инфраструктуры на базе VMware на примере ПАК «Аккорд-В.»
ПАК «Аккорд-В.» обеспечивает защиту всех компонентов среды виртуализации: ESXi-серверов и самих виртуальных машин, серверов управления vCenter и дополнительных серверов со службами VMware (например, VMware Consolidated Backup).
Система защиты ПАК «Аккорд-В.» полностью интегрируется в инфраструктуру виртуализации, поэтому для ее функционирования не требуются дополнительные серверы. При этом ПАК «Аккорд-В.» не ограничивает в целях безопасности возможностей виртуальной инфраструктуры, оставляя доступными все ее преимущества.
В ПАК «Аккорд-В.» реализованы следующие механизмы защиты:
- Доверенная загрузка всех элементов инфраструктуры виртуализации.
- Пошаговый контроль целостности гипервизора, виртуальных машин, файлов внутри виртуальных машин и серверов управления инфраструктурой.
- Разграничение доступа администраторов виртуальной инфраструктуры и администраторов безопасности.
- Разграничение доступа пользователей внутри виртуальных машин.
- Аппаратная идентификация всех пользователей и администраторов инфраструктуры виртуализации.
- Управление системой защиты осуществляется централизованно с сервера управления виртуальной инфраструктурой. Доступ к инструментам управления системой защиты предоставляется только администраторам безопасности, от администраторов виртуальной инфраструктуры эти инструменты скрыты.
Защиту инфраструктуры на базе Hyper-V рассмотрим на примере ПАК «ГиперАккорд»
Интерфейс управления комплекса аналогичен ПАК «Аккорд-Win32» и «Аккорд-Win64», поэтому необходимость переучивания управляющего персонала минимальная.
В «ГиперАккорд» реализованы следующие механизмы защиты:
- Идентификация/аутентификация пользователей до загрузки ОС;
- Проверка целостность критичных для работы службы Hyper-V программ, данных и ветвей реестра до загрузки ОС;
- Аутентификация администраторов виртуальной инфраструктуры и администраторов информационной безопасности;
- Разграничение доступа пользователей к серверу Windows 2008;
- Разграничение доступа к файлам и данным службы Hyper-V;
- Разграничение доступа к виртуальным или физическим дискам виртуальных машин;
- Защита средств управления виртуальной инфраструктурой от НСД;
- Контроль запуска виртуальных машин;
- Контроль целостности конфигурации виртуальных машин;
- Контроль целостности файлов и данных виртуальных машин (виртуальных дисков);
- Доверенная загрузка виртуальных машин.
Для обеспечения полноценной защиты виртуальных машин от НСД, рекомендуется на виртуальных машинах использовать
ПАК «Аккорд-Win32», «Аккорд-Win64» или
«Аккорд-Х».
Комплекс работает на всех версиях Hyper-V (версии 2 и 3 — для Windows 2008 R2 и 2012 соответственно).
Если ЦОД может доказать свою безопасность для использующих его клиентов, подтверждением своей защищенности теми или иными средствами, аттестатом соответствия, и так далее, то рассчитывать на такие же подтверждения со стороны пользователей, конечно, невозможно.
При этом такой незащищенный клиент подвергает опасности не только себя (считая, что он защищен, раз облако – защищенное), но и сам ЦОД, создавая совершенно классическую «дыру в заборе». А стало быть, не в безопасности и другие клиенты ЦОДа.
Существенно сложнее, чем обеспечение безопасности облака для клиента, задача обеспечения безопасности облака от клиента . Строго говоря, в общем случае невозможно решить задачу доверия произвольно выбранному пользователю. И в наиболее общей постановке все пользователи (представители потребителя) для облака являются недоверенными.
Для доверия облака пользователю необходим механизм контроля его вычислительной среды.
Доверенная среда на компьютерах пользователей
Интуитивно ясно, что такое доверенная среда. Ключевым здесь является слово «доверие». Доверие — это не абсолютная характеристика. Более или менее доверяем мы той или иной декларации — вполне нормальная постановка задачи. Чтобы на этом поле сократить объемы разговоров и спекуляций, регулятор выделил 6 типов нарушителя — от самого простого (например, может случайно сфотографировать экран компьютера на телефон) (Н1), до наиболее квалифицированного и снабженного всеми необходимыми средствами — Н6. Соответственно обозначено разделение средств по этой характеристике — КС1, КС2, КС3, КВ1, КВ2, КА1. Средство, сертифицированное по классу КС1 может успешно противостоять нарушителю Н1, КВ2 — нарушителю Н5. Для понимания градации следует сказать, что нарушитель Н3 — по сути, компьютерный недоучка, который только и умеет, что скачать из Интернета программу и запустить ее.
Несмотря на всю размытость (нечеткость) такой классификации, нужно понимать, что в Интернете имеется множество хакерских программ, и уж точно много троянов, перехватчиков управления, перехватчиков паролей и других разрушающих программных воздействий. В связи с этим, есть ряд мер по защите криптографических средств от несанкционированного доступа, которые должны быть реализованы обязательно — это:
- обеспечение целостности проверенного программного обеспечения и данных;
- управление доступом пользователя к компьютеру;
- разграничение доступа к программам и данным.
Однако практика подсказала, что создать доверенную среду мало — ее нужно поддерживать на всем жизненном цикле. Действительно, если информационная система меняется - а она меняется, — то однажды зафиксированное состояние всегда может измениться, и в нелучшую, с точки зрения информационной безопасности, сторону. Значит, доверенную среду нужно не только создать, но и поддерживать.
Но как, же сделать так, что бы доверенность среды поддерживалась постоянно?
Заметим, что любое информационное взаимодействие можно представить как взаимодействие клиентов через сервис. Если со стороны сервиса всегда можно обеспечить достаточный уровень квалификации персонала, и, соответственно, достаточный уровень информационной безопасности, то обучить всех клиентов всех сервисов приемлемому уровню знаний об информационной безопасности решительно невозможно. Пока не удается даже научить всех грамотно писать и говорить.
Оказывается, что, так как приемлемый уровень квалификации со стороны клиента недостижим в принципе, то при организации защиты неквалифицированные действия обязательно создадут «дыру» в защищенности. Очевидно, что делать забор все выше и выше бессмысленно, пока в заборе остаются дыры. Бессмысленно все лучше и лучше защищать сервисы, пока «дыра» у клиента.
Что же делать?
Ответ очевиден — средства клиента должны быть ненастраиваемые, а все действия по управлению безопасностью должны быть переданы профессионалам. Простой вывод, но в научный оборот он вводится только сейчас.
А всегда ли клиент какого-либо доверенного сервиса должен работать в доверенной среде? Вряд ли. Это будет слишком высокая цена за удовольствие, например, получить раз в месяц госуслугу в электронном виде. Скорее, клиенту нужно часто работать в недоверенной среде, и лишь иногда организовывать доверенный сеанс связи с доверенным сервисом.
Таким образом, работа в доверенном режиме может осуществляться все время, а может лишь иногда, в относительно небольшие интервалы времени. В первом случае мы создаем доверенную вычислительную среду (ДВС), во втором — организовываем доверенный сеанс связи (ДСС).
ДВС создается однократно, но стоимость создания относительно велика. Действительно, однажды созданная, ДВС должна поддерживаться за счет СЗИ долго, в отдельных случаях — годы. За это время суммарное количество атак может стать огромным, и все эти атаки должны быть отражены защитными механизмами СЗИ. Конечно, такие СЗИ стоят дорого.
ДСС создается каждый раз заново, и это в ряде случаев может быть неудобно - загрузка и проверочные мероприятия продолжаются 30-50 секунд, но средства ДСС стоят гораздо дешевле, так как длительность ДСС не всегда достигает и 20 минут.
Вот в этом и состоит основная идея доверенного сеанса связи и его отличие от традиционного подхода. С этим связана и методика выбора — если вы все время должны быть в доверенной среде — создавайте и поддерживайте ДВС. Если доверенность нужна лишь иногда — достаточно и удобнее применять ДСС.
Для этого случая нужно предложить устройство, с которого могла бы осуществляться загрузка, оно было бы отчуждаемым и не теряло бы своих свойств при атаках.
Хорошим вариантом является USB-устройство. Конечно, оно должно быть не простой памятью — если память устройства находится в адресном пространстве компьютера — это устройство не может выполнять функции защиты.
Специализированное устройство получило название «МАРШ!».
Конструктивно «МАРШ!» выполнен в виде USB-устройства, и выглядит точно так же, как обычная «флешка». Такой конструктив позволяет использовать «МАРШ!»практически со всеми компьютерами, так как почти все компьютеры имеют достаточное количество портов USB.
Тем не менее, «МАРШ!» похож на флешку только внешне. На самом деле это активное микропроцессорное устройство, с многоконтурной криптографической подсистемой, проверенной защищенной операционной системой Linux, браузером, специальной подсистемой управления к памяти и многим другим.
Основная задача «МАРШ!»а — создание доверенной среды функционирования криптографии. Для этого в специальном разделе памяти «МАРШ!»а размещается все необходимое для этого программное обеспечение. Важнейшей особенностью является обеспечиваемая «МАРШ!»ем возможность подписи документов в формате XML.
«МАРШ!» подготавливается к эксплуатации как загрузочное устройство. При начале доверенного сеанса связи пользователь загружается с «МАРШ!» а, обеспечивая тем самым доверенную среду. Далее стартует браузер и все сопутствующее программное обеспечение, необходимое для работы. В браузере в доверенном сеансе обеспечивается защищенный обмен информацией, с соблюдением всех требований 63-ФЗ.
Загрузка производится из защищённой от записи памяти, жёсткий диск компьютера не используется. Конфигурация загруженной операционной системы максимально ограничивает свободу пользователя: ему недоступны органы управления операционной системы, рабочая среда полностью изолирована от посторонних сетевых соединений, открытый трафик отсутствует, после завершения работы в браузере сеанс связи завершается, не давая пользователю делать лишнего.
После загрузки ОС на компьютер клиента и старта браузера устанавливается доверенный сеанс связи с сервером (VPN-шлюзом) центральной ИС, т.е. защищённое соединение на основе криптографических алгоритмов (закрытые ключи и сертификаты хранятся в защищённой памяти «МАРШ!»). Сервер ИС выполняет авторизацию пользователя на доступ к сервисам ИС и соединение с требуемым сервисом ИС.
Способ реализации ДСС за счет динамического формирования доверенной вычислительной среды инвариантен относительно используемых технологий и конфигураций средств вычислительной техники и расширяет общепринятый подход к обеспечению безопасности информации. Исчезает также «привязанность» пользователя и средств обеспечения информационной безопасности к конкретной рабочей станции.
Итак, с применением «МАРШ!»:
- состояние критичных компонентов зафиксировано
- вирусы блокированы
- ключи неизвлекаемые
- перехват управления невозможен
- управление безопасностью отчуждено от клиента
Очевидно, что не во всех без исключения случаях целесообразно защищать клиентские рабочие места только с помощью
«МАРШ!».
В этом смысле необходимо учитывать два обстоятельства:
1. являются ли пользовательские рабочие места контролируемыми (это так, если ЦОД корпоративный и пользователи — сотрудники организации, но не так — если это ЦОД, предоставляющий облачные сервисы неограниченному кругу пользователей, использующих неограниченный круг компьютеров);
2. ПЭВМ или тонкие клиенты используются в качестве рабочих мест пользователей.
Легко заметить, что эти вопросы находятся в иерархической связи и дают следующие варианты систем:
1) Фиксированные рабочие места пользователей, контролируемые (управляемые) службой информационной безопасности (относится она к владельцу ЦОДа или нет — вопрос в данном случае второстепенный; достаточно знать, что какой-то службой информационной безопасности — контролируются).
2) неизвестный и неконтролируемый парк СВТ.
Очевидно, что «МАРШ!» — это единственный приемлемый вариант для случая с неизвестным и неконтролируемым парком клиентских мест.
Столь же очевидно, что в случае, когда рабочие места — фиксированные, контролируются службой безопасности и представляют собой ПЭВМ, то почти наверняка они используются не только для взаимодействия с ЦОДом, но и автономно. И значит, они должны быть защищены полноценным программно-аппаратным комплексом СЗИ НСД (например, ПАК «Аккорд-Win32» или «Аккорд-Win64», в зависимости от разрядности ОС на этих ПЭВМ). В зависимости от политики безопасности запуск ВМ может требовать от пользователя подключения, например, другого идентификатора.
Важно понимать, что даже в том случае, если единственной задачей пользователя ПЭВМ является работа с виртуальной инфраструктурой, все равно необходима установка именно ПАК, ограничиваться только Аккордом-АМДЗ — неверно, так как даже если пользователь не должен, он может использовать ОС своего компьютера для каких-либо не установленных ему задач, и контролировать потенциальный общий ресурс — необходимо.
Применение тонких клиентов, как правило связано с тем, что локально задачи пользователями не выполняются или они минимальны. В то же время, ОС тонких клиентов тоже должна быть доверенной. И в этом случае целесообразно применять либо «МАРШ!», либо — если пользователи работают в терминальном режиме с виртуальным терминальным серверов — ПАК «Центр-Т», обеспечивающий защищенное хранение и доверенную сетевую загрузку образов ПО терминальных станций с подтверждением их целостности и аутентичности.
Применение ПАК «Центр-Т» удобно в тех случаях, когда актуальна задача обновлений и разного другого рода модификаций образов терминальных станций без приостановки эксплуатации системы в штатном режиме. На специальном АРМ «Центр» (который реализован на ПСКЗИ ШИПКА и загружается на произвольный ПК, не оставляя на нем после отключения ШИПКИ никаких следов) Администратор редактирует образы ОС, вырабатывает коды аутентификации (КА) для контроля их целостности и аутентичности, и записывает их на другую ШИПКУ, с которой загружается на произвольный ПК «Сервер хранения и сетевой загрузки», с которого в свою очередь, их получают по сети клиентские ШИПКИ и загружают после проверки КА. За счет того, что целостность и аутентичность образов контролируется с помощью КА, а не контрольных сумм, и достигается ключевой эффект — защищенное обновление образов без организационных сложностей и остановки работы.
При этом с точки зрения действий пользователей система практически не будет отличаться, с одной стороны, от построенной на базе «МАРШ!», а с другой — от «реальной» терминальной системы: пользователь будет подключать USB-устройство, вводить PIN-код и ожидать загрузки терминала и старта сессии с терминальным сервером. Что он виртуальный — пользователь может и вовсе не знать. В рамках сессии то же USB-устройство выполняет функцию идентификатора пользователя в ПАК СЗИ НСД на серверной части системы.
***
Доверие между человеком и облаком и уверенность в надежном фундаменте воздушного замка – это нормально. Бывают в нашем мире и более странные вещи, а то ли еще будет. Просто в основе любого доверия и всякой уверенности должны лежать ясные инженерные решение.
