Защита серверов в гибридном облаке с помощью Kaspersky Security для виртуальных и облачных сред

Расширение информационной среды организации за счет использования публичных облачных сервисов (таких как Amazon Web Services или Microsoft Azure) ставит проблемы защиты разнородной инфраструктуры от внутренних и внешних угроз. В условиях, когда часть данных хранится локально, а часть — находится у внешнего поставщика услуг, добиться однородной и последовательной безопасности трудно. Каковы негативные последствия разнобоя между операционными системами / физическими и виртуальными машинами / локальными и публичными ресурсами и как эти последствия преодолеть.

 

 

 

1. Введение
2. Что такое гибридное облако?
3. Гибридному облаку – гибридные угрозы
4. Формулируем требования к системе защиты
5. Kaspersky Security для виртуальных и облачных сред в гибридном облаке
1. 5.1. Защита виртуальных серверов on-premise (за счет собственных ресурсов)
2. 5.2. Защита физических серверов
3. 5.3. Защита серверов в публичном облаке
6. Выводы

 

Введение

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

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

Сосредоточимся на том, что собой представляет гибридное облако, каковы сферы его применения, ключевые изъяны и риски, а также попытаемся разобраться в том, как обеспечивается безопасность подобной инфраструктуры. Примером защитного решения, охраняющего гибридные облака, послужит Kaspersky Security для виртуальных и облачных сред (KHCS).

 

Что такое гибридное облако?

Национальный институт стандартов и технологий США предлагает универсальное определение, суть которого такова: гибридной можно считать любую конструкцию из нескольких самостоятельных облаков, которые соединены интерфейсом, сшивающим их в единое вычислительное пространство. Тогда облака, с одной стороны, сохраняют целостность (т.е. не сливаются в нечто третье), а с другой стороны, получают возможность обмениваться приложениями и данными. При этом подходе гибрид может состоять из однотипных элементов — например, нескольких частных инфраструктур.

 

Рисунок 1. Модель гибридного облака

 

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

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

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

Еще один вариант — резервирование: в публичном облаке можно разместить «копию» частного, чтобы при сбоях в работе основной инфраструктуры можно было быстро и безболезненно переключиться на запасную. Этот случай похож на первый, однако отличается от него тем, что здесь речь идет не о дополнительных мощностях на случай перегрузок, а о дублировании данных и приложений.

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

 

Рисунок 2. Типовой сценарий перехода на гибридное облако: малозатратные приложения работают локально, в то время как высокая нагрузка делегируется вовне

 

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

Помимо прочего, одно из главных достоинств рассматриваемой схемы — относительная безопасность: критически важные приложения и данные остаются внутри частного облака, где вероятность их компрометации ниже. Именно из этих соображений исходят руководители, которые предпочитают гибрид полному переходу в публичное облако: внешняя инфраструктура тоже неплохо защищена, но хранить свои активы лучше у себя, чем «где-то далеко». Такой подход вполне разумен, хотя, возможно, и отличается несколько чрезмерной осторожностью. Однако переход к использованию гибридного облака все равно влияет на защищенность информации, а следовательно, нужно обратить внимание на риски, которые могут быть с этим сопряжены.

 

Гибридному облаку — гибридные угрозы

Основная и наиболее очевидная проблема, связанная с расширением облака, заключается в том, что периметр «растягивается», и у потенциального злоумышленника возникает больше возможностей для нападения. Если до этого в защите нуждалась только локальная инфраструктура, то теперь атака может прийти со стороны тех узлов, которые вынесены в публичное облако. Поскольку отправленные «наружу» данные и приложения находятся теперь под контролем внешнего поставщика, организация уже не может принять исчерпывающие меры для обеспечения их безопасности и вынуждена полагаться на добросовестность третьей стороны. Кроме того, вероятных «точек входа» для киберугроз становится банально больше, а следовательно, риск компрометации пропорционально увеличивается.

Выше мы упоминали о том, что гибридное облако — это несколько самостоятельных инфраструктур, которые становятся единым пространством. Этот факт имеет свои последствия, в том числе и с точки зрения безопасности. Важное достоинство гибрида — беспрепятственная и «бесшовная» передача информационных активов из частного облака в публичное и обратно — превращается в потенциальный изъян, потому что таким образом может нарушиться их конфиденциальность. Говоря иначе, данные могут оказаться там, где им не следует находиться: есть вероятность, что информация из частного облака попадет в публичное, причем не обязательно случайно. Поскольку режим конфиденциальности у частных и публичных облаков отличается, возможны инциденты.

Еще одно уязвимое место гибридного облака — это интерфейс, который соединяет его части между собой. Он должен уметь решать некоторые задачи, связанные с безопасностью, — например, поддерживать контроль доступа пользователей к данным. Впрочем, стоит заметить, что распределение прав — это проблема не одного лишь интерфейса, но и всей инфраструктуры в целом. Общеизвестно, что множество угроз возникает изнутри, т. е. свои собственные сотрудники создают больше проблем, чем злоумышленники извне. Соответственно, гибридное облако должно иметь надежный контроль доступа к данным и продуманную систему прав, потому что в противном случае пользователи могут получить чрезмерные полномочия. Сюда же можно отнести управление устройствами, которые обращаются к облаку (главным образом смартфонами и планшетами), а также идентификацию и аутентификацию пользователей. В сложной конструкции вроде гибридного облака трудно уследить за тем, кто чем занимается, поэтому бесконтрольный доступ или плохо проработанные права могут создать большие проблемы.

Кстати, сложность конструкции сама по себе является одним из рисков в области безопасности. На этот фактор обращают внимание почти во всех рекомендациях по защите гибридных облаков. Крупномасштабная разветвленная инфраструктура, которая «разбросана» по множеству локальных и удаленных серверов и дата-центров, плохо просматривается на предмет несанкционированной активности. Для того, чтобы предотвращать инциденты или правильно на них реагировать, нужно четко понимать, что происходит, и вовремя замечать подозрительные события и аномалии. Непрозрачность же гибридного облака приводит к тому, что действия злоумышленников остаются незамеченными на весьма долгое время — вплоть до нескольких месяцев.

Можно упомянуть также о проблеме безопасной передачи данных, поскольку для обмена информацией с публичным облаком нужно соединяться с ним через сети общего пользования. Чтобы избежать атак через внедренного посредника (man in the middle) и других способов перехвата, необходимо пользоваться шифрованием, прибегать к возможностям VPN, прокси-серверов и других подобных инструментов.

Перечисленные угрозы можно считать основными, хотя список вероятных проблем ими не исчерпывается. Посмотрим на то, как можно учесть их при обеспечении безопасности.

 

Формулируем требования к системе защиты

Итак, исходя из тех уязвимых мест, которые мы указали выше, можно опираться на следующие критерии.

1. Система защиты должна обеспечивать равноценную безопасность для всех информационных активов независимо от того, где они находятся — в частном облаке или в публичном. Эксплуатант должен быть уверен в том, что его политика безопасности действует одинаково применительно к любым данным.
2. Система защиты должна отслеживать и контролировать активность приложений и устройств, позволяя управлять тем, с какими данными может работать каждое из них. То же касается и контроля доступа пользователей к информационным ресурсам, включая защиту самих пользователей от угроз наподобие фишинга.
3. Защитное решение должно обеспечивать прозрачность процессов, происходящих в облаке, позволяя оперативно реагировать на подозрительные события и инциденты. Полезно иметь единообразное централизованное управление, которое облегчало бы администрирование системы безопасности — с учетом «пестроты» инфраструктуры гибридного облака.
4. Целесообразно подкреплять ручной анализ событий средствами обнаружения и предотвращения вторжений (IDS/IPS), которые следили бы за подозрительным трафиком и выявляли сомнительную активность.
5. Поскольку гибридное облако состоит из множества разнотипных элементов, защита должна быть многоуровневой. Очевидно, что, например, вредоносные программы могут с равным успехом атаковать любые конечные точки и рабочие места пользователей — в том числе и те, которые созданы с помощью виртуализации.

Также стоит указать на дополнительные требования, которые не связаны с угрозами напрямую, но имеют опосредованное влияние на эффективность системы в целом.

1. Так как гибридное облако часто создается для решения проблем производительности, система защиты должна создавать сравнительно небольшую нагрузку на инфраструктуру, не жертвуя при этом надежностью. Известна традиционная дилемма антивирусного программного обеспечения, где глубокий анализ требует значительных ресурсов, а быстродействия приходится достигать за счет поверхностного сканирования.
2. Естественно и логично ожидать того, чтобы защита поддерживала как можно больше облачных платформ, средств виртуализации и операционных систем. Чем проще и универсальнее решение, тем более эффективно оно будет работать.
3. Крупные поставщики облачных услуг — например, Amazon или Microsoft — развивают возможности машинного обучения для того, чтобы повысить качество услуг и удобство работы с облаком. Логично искать такое защитное решение, которое могло бы извлекать пользу из преимуществ, предоставляемых машинным обучением и средствами автоматизации операций — такими, скажем, как обнаружение новой инфраструктуры и распространение на нее политики безопасности.

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

 

Kaspersky Security для виртуальных и облачных сред в гибридном облаке

KHCS представляет собой оркестр из довольно большого количества инструментов, каждый из которых отвечает за какой-либо из аспектов безопасности гибридной среды. Таким образом, перед нами — одна глобальная лицензия, в рамках которой можно пользоваться сразу несколькими продуктами:

• Kaspersky Security для виртуальных сред (агентская версия и решение без агента)
• Kaspersky Endpoint Security для Linux
• Kaspersky Security для Windows Server
• Kaspersky Security для виртуальных и облачных сред (AWS и Azure)

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

Поэтому мы не слишком преувеличим, если назовем ключевым компонентом этого решения Kaspersky Security Center — сервер администрирования и консоль управления. Он отвечает за многие важные задачи: помимо настройки программ, центр обеспечивает развертывание защиты в виртуальных и облачных средах, создает дистрибутивы для установки агентских приложений и т. п. Через него оказываются связанными все продукты, перечисленные в списке выше. Тем самым достигается столь важное единообразие конфигурации, равно как и прозрачность инфраструктуры. 

 

Защита виртуальных серверов on-premise (за счет собственных ресурсов)

Для виртуализации на собственных ресурсах может использоваться приложение Kaspersky Security для виртуальных сред (KSV), которое существует в двух вариантах: с агентским приложением и без него. Исполнение без агента основано на технологии, позволяющей защищаться от вирусов на уровне гипервизора. В такой конфигурации не требуется устанавливать на виртуальные машины никакие приложения, что дает значительное преимущество в производительности; однако этот вариант подходит только для средств виртуализации VMWare. Кроме того, при данном подходе невозможно реализовать многие защитные функции — такие, например, как проактивная защита и механизмы эвристического анализа, без которых трудно обнаруживать сложные угрозы, скрывающиеся от файлового антивируса. С подобными ситуациями может справиться только агентское решение, на котором мы сосредоточимся далее.

Структурно KSV с легким агентом состоит из трех частей: собственно агента, сервера защиты и сервера интеграции. Агент устанавливается на виртуальные машины, нуждающиеся в охране, сервер защиты разворачивается в виде отдельной виртуальной машины и берет на себя все ресурсоемкие задачи (в частности, именно на нем находятся антивирусный движок,  сигнатурные базы и разнообразные механизмы проверки и обнаружения вирусов), а сервер интеграции обеспечивает взаимодействие между компонентами программы, позволяя тем самым добиться отказоустойчивости и автоматизировать процессы управления.

 

Рисунок 3. Компоненты KasperskySecurityдля виртуальных сред с агентом

 

Практика защиты серверов с помощью KSV имеет существенное отличие от его же работы с конечными точками. Строго говоря, агентское приложение предназначено в первую очередь для терминалов под управлением обычных клиентских выпусков Windows. Именно в этой среде решение может продемонстрировать все те возможности, которые в него заложены: контроль активности программ, контроль устройств, мониторинг системы и т. д. Безопасность серверов обеспечивается точно так же — установкой агента, — однако спектр его возможностей сужается.

На виртуальные машины под управлением серверных выпусков Windows можно установить следующие компоненты KSV:

1. Файловый антивирус. Элемент проверяет файлы на предмет заражения по мере доступа к ним. В интересах производительности KSV использует систему кэширования, которая запоминает просканированные объекты и избегает их повторной проверки, если тот же самый файл появляется на другой виртуальной машине из той же сети. Каждый экземпляр агента имеет и свой собственный локальный кэш, который дает возможность ускорить проверку на конкретной машине, не обращаясь к глобальному кэшу всего хоста.
2. Сетевой экран. Так же, как и в других продуктах «Лаборатории Касперского», брандмауэр руководствуется двумя наборами правил: для конкретного приложения (правила для программ) и для сетевой активности в целом (правила для пакетов). Сетевой экран играет роль средства борьбы с уязвимостями, предотвращая их эксплуатацию извне при подключении виртуальной машины к интернету. «Побочным эффектом» этой работы становится защита персональных данных, хранящихся на виртуальной машине, от компрометации. Компонент автоматически назначает статусы новым сетям, однако центр управления безопасностью позволяет переопределить сети как публичные, локальные или доверенные.
3. Защита от сетевых атак. Этот компонент наблюдает за входящими соединениями и блокирует компьютеры, запросы от которых имеют признаки известных сетевых атак. Сигнатуры атак хранятся в антивирусных базах и обновляются вместе с ними. При необходимости можно изменить параметры блокировки атакующих компьютеров или сформировать список доверенных IP-адресов.
4. Контроль запуска программ. Эта функциональность позволяет управлять правами пользователей на запуск приложений, а также следить за тем, с какими программами работают сотрудники организации. Контроль запуска программ руководствуется правилами, которые нацелены на реализацию принципа Default Deny: пользователям запрещено запускать любые приложения, кроме тех, относительно которых задано явное разрешение. Этот подход обеспечивает полную работоспособность операционной системы и тех приложений, которые требуются сотрудникам для выполнения их обязанностей, однако препятствует запуску любых новых программ, которые не были одобрены администратором. Предусмотрен также механизм отправки жалоб, благодаря которому пользователь может запросить разблокировку приложения. При желании или необходимости, впрочем, блокировку можно заменить на уведомление.
5. Контроль целостности системы (FIM). Здесь идет речь о предотвращении нежелательных изменений в операционной системе виртуальной машины. Компонент охватывает такие ключевые составляющие операционной системы, как файлы и реестр; кроме того, он контролирует подключение внешних устройств. Доступна возможность следить за системой в режиме реального времени или путем периодических проверок по расписанию или по требованию.

В свою очередь, на виртуальные машины под управлением Linux устанавливаются только первый и последний компоненты этого списка — файловый антивирус и контроль целостности.

 

Защита физических серверов

В целях обеспечения безопасности физических серверов используются продукты Kaspersky Security для Windows Server и Kaspersky Endpoint Security для Linux. Название второго продукта не должно вводить в заблуждение: несмотря на слово Endpoint, т. е. «конечные точки», он позволяет защищать и сервера.

Экземпляр Kaspersky Security для Windows Server, который входит в состав KHCS, имеет следующие базовые модули:

• Файловый антивирус
• Защита от эксплойтов
• Сетевой экран
• Защита от внешнего шифрования (Anti-Cryptor)
• Контроль устройств
• Веб-контроль
• Веб-антивирус
• Плагин для Outlook

Расширенная версия этого же продукта (с пометкой Enterprise) дополнительно содержит мониторинг файловых операций, анализ журналов и контроль запуска программ.

Многие из этих компонентов комментировались выше. Стоит отметить элемент Anti-Cryptor, который является ответом на многолетнюю популярность вредоносных программ-шифровальщиков. Этот компонент защищает папки общего доступа, с которыми пользователи могут взаимодействовать по протоколу SMB. По характерным изменениям, происходящим в такой папке, он определяет, что идет процесс шифрования содержимого, и прерывает его, а также сообщает администратору об инциденте.

Также можно обратить внимание на компонент «Контроль устройств», который позволяет настраивать права доступа пользователей к дисководам, модемам, принтерам и коммуникационным интерфейсам вроде Bluetooth, и на модуль «Веб-контроль», предназначенный для фильтрации нежелательных сайтов. Эти функции есть и в решении для виртуальных сред, однако там они могут работать только в клиентских операционных системах Windows.

Продукт Kaspersky Endpoint Security для Linux, в свою очередь, поддерживает такие задачи, как:

• Файловый антивирус (постоянная защита, проверка по требованию, сканирование загрузочных секторов и памяти)
• Контроль целостности системы (мониторинг файловых операций)
• Сетевой экран
• Защита от внешнего шифрования

Ландшафт угроз для Linux по-прежнему существенно меньше, чем для Windows, но оставлять такие серверы без охраны, тем не менее, рискованно.

 

Защита серверов в публичном облаке

Здесь доступны два решения: для гибридных облаков в AWS и в Azure. Содержательно они представляют собой рассмотренные выше Kaspersky Security для Windows Server и Endpoint Security для Linux, которые доступны через соответствующий магазин приложений (Marketplace) и могут быть подключены к публичной облачной инфраструктуре за несколько щелчков мышью.

В варианте для AWS наряду с антивирусной защитой доступны следующие возможности:

• Борьба с эксплойтами
• Контроль целостности
• Анализ журналов
• Контроль программ
• Контроль активности приложений
• Защита от внешнего шифрования

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

Вариант для Azure поддерживает мониторинг файловых операций (контроль целостности системы), имеет сетевой экран и снабжен модулем Anti-Cryptor.

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

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

 

Выводы

Гибридное облако имеет свои преимущества в сравнении с другими вариантами облачной инфраструктуры, и исследования Gartner предсказывают, что к 2020 году 90% организаций будут пользоваться теми или иными разновидностями гибридов. Естественно ожидать, что, с одной стороны, будет расти давление на подобные системы со стороны злоумышленников, а с другой стороны, эксплуатанты будут заинтересованы в укреплении их защиты. Некоторые особенности гибридного облака делают его более контролируемым и безопасным, чем публичная инфраструктура, однако следует иметь в виду, что у него есть и уязвимые места.

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

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

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