Что нужно учесть на старте, чтобы сделать облако безопасным
Привет! Я Виктор Бобыльков — CISO MWS. В этой статье расскажу, как обезопасить облако физически и инфраструктурно, как правильно использовать Red Teaming, чтобы натренировать Security Operation Center, и спасти клиентов от кибератак.
От чего нужно обезопасить облако
У облачной платформы есть обязательства перед клиентами в области безопасности. Облако отвечает за физическую безопасность ЦОДов, безопасность разрабатываемых им сервисов, а клиент управляет доступами к данным в своей виртуальной инфраструктуре, например, самостоятельно реализует принцип наименьших привилегий среди своих сотрудников.
Между клиентом и сервисом ответственность распределяется по-разному, допустим, компании, которые пользуются on-prem-методом, отвечают за сохранность и безопасность данных без оглядки на кого-то, а о безопасности данных клиентов облака заботится облачный провайдер. В зависимости от модели предоставления услуг: Iaas, PaaS, Saas это модель разделения рисков изменяется.
Как делится ответственность за безопасность данных между клиентом и моделями сервисов
Давайте поговорим об угрозах, которые должен учесть провайдер для всесторонней защиты облака.
Атаки на ключевую инфраструктуру
Начнём с обеспечения физической безопасности серверов, чтобы никто без нужного уровня доступа не прошёл в машинный зал ЦОДа. Во всех дата-центрах необходим пропускной режим, контроль доступа к стойкам и круглосуточное видеонаблюдение.
Кроме того, как мы знаем, облачная инфраструктура состоит из двух ключевых компонентов: Control Plane и Data Plane. Control Plane — сердце облака и требует особой защиты от атак на его составляющие, такие как Network, Compute и Storage. Обеспечение безопасности этих элементов — критически важная задача для облачных провайдеров.
Control Plane и Data Plane
Control Plane — управляющий слой, Data Plane — передающий слой. Два основных уровня, которые отвечают за управление сетями, приложениями, облачными платформами. Они работают совместно, но один слой изолирован от другого. Control Plane отвечает за логику и стратегические решения, а Data Plane следит за выполнением этих решений и передачу данных.
Атаки на цепочки поставок
Другой тип угроз — атаки на цепочку поставок. Они могут осуществляться через поставку заражённого программного обеспечения от вендоров или через уязвимости в процессе разработки. Сюда же относятся атаки, связанные с уязвимостями в компонентах и зависимостях при разработке сервисов.
Отдельно стоит упомянуть side-channel-атаки, которые эксплуатируют уязвимости в процессорах, например Spectre и Meltdown, обнаруженные в 2017 году, или атаки на оперативную память.
В любом ПО, даже если его создают самые крутые разработчики, могут быть уязвимости. Их обнаруживают сами компании, хакеры или багхантеры, — это повседневный процесс. Важно регулярно ставить патчи. Например, в России популярна платформа 1С, которая требует своевременных обновлений для поддержания безопасности. Облачный провайдер обязан постоянно следить за безопасностью своих платформ и платформ партнёров, включая управление Kubernetes-кластерами, для обеспечения безопасности своих клиентов.
Все эти варианты угроз указывают на важность комплексного подхода к обеспечению кибербезопасности облачной среды, необходимость постоянного мониторинга и обновления систем защиты.
Примеры атак и мер противодействия
В качестве примера расскажу про атаку на dom0. Dom0 — это нулевой привилегированный домен, инертный статический узел, его главная задача — запуск виртуальных машин. Такая атака проходит одновременно и легко, и сложно. Легко, потому что можно получить законный доступ к виртуальной машине, например купить ее как клиент. А сложность заключается в том, что существует малое количество выявленных уязвимостей.
Ещё возможны атаки на Control Plane. Допустим, через стандартные сервисы платформы, например через сервис метаданных.
Дальше у злоумышленника есть пара вариантов. Первый вариант — атака на виртуальную машину данного хоста и получение доступа к сетям клиента для того, чтобы уже получить дальнейшие доступы. Второй — атака на Control Plane, допустим на compute, для того, чтобы получить доступ к управляющей инфраструктуре облака.
Такую атаку можно обнаружить при регулярном мониторинге. Как выше изложено, dom0 — это статичный инертный узел, на него должны ходить только технологические учётные записи. Например, мы можем установить «технологические окна», то есть определить специальное время для администрирования, допустим, каждый четверг с 5 до 6 вечера. И если замечаем активность не в этот временной промежуток — это инцидент информационной безопасности. Мы должны отреагировать на него моментально, потому что это очень критичный узел.
Стандартно мы должны вести мониторинг всевозможной вредоносной сетевой активности на хосте. Мы следим за запуском приложений не из нашего белого списка. И ещё мы всегда должны быть готовыми к оперативному обновлению KVM-QEMU.
О чём ещё важно подумать для безопасности облака
Надёжное облачное решение требует комплексной защиты: физических и инфраструктурных уровней. Ниже расскажу подробнее.
Эшелонированная защита
Мы придерживаемся принципа многоэшелонированной защиты — defense in depth. Такая стратегия предполагает, что, даже если скомпрометирован какой-то уровень безопасности, невозможно проникнуть дальше. И самое главное, мы сможем увидеть злоумышленника на скомпрометированном эшелоне безопасности и предпримем меры, чтобы остановить атаку.
Defense in depth спасает от разных уязвимостей в программном обеспечении или от человеческого фактора. Допустим, инженеры на стороне клиента для своего удобства могут открыть доступ к управляющим портам или базам данных извне, что создаёт серьёзные уязвимости и подвергает систему значительным рискам.
Организованные проверки безопасности
Отдельно хотел бы остановиться на практике Red Teaming — это процесс имитации кибератаки. Её проводят наши коллеги, у нас есть собственная Red Team, которая имитирует действия внешнего нарушителя, либо гостя, либо сотрудника уже с набором доступов. Red Team пытается незаметно захватить инфраструктуру, чтобы закрепиться в ней и получить критические данные, либо нарушить безопасность облака. Тут мы проверяем работу Security Operation Center, потому Red Teaming пытается взломать, а Security Operation Center должен предотвратить атаку.
Безопасность инфраструктуры
Чтобы защитить сервисы, мы используем межсетевые экраны нового поколения, VPN-соединения, анализ сетевого трафика, защиту от DDoS-атак и системы управления уязвимостями.
Особое внимание уделяем управлению доступом. Это позволяет контролировать действия всех субъектов, отслеживать права и доступы.
Ещё важно придерживаться «правильного» администрирования. Считаю, администраторы должны иметь несколько учётных записей, каждая из которых предназначена для управления конкретным элементом инфраструктуры. Это делается для того, чтобы в случае компрометации одной учётной записи злоумышленники не получили доступ ко всей системе.
Важную роль в этом процессе играет центр обеспечения безопасности (Security Operation Center, SOC). Его задача — следить за правильностью администрирования и предотвращать несанкционированные действия, например попытки администратора расширить права доступа своей учётной записи.
Подробнее стоит рассмотреть процесс управления уязвимостями — vulnerability management как на внешнем периметре, так и внутри системы. Это один из ключевых процессов практической безопасности, который мы выстраиваем.
Процесс начинается с инвентаризации всей инфраструктуры и создания её «слепка» для выявления уязвимых компонентов. Параллельно мы мониторим новые уязвимости и анализируем, как они могут повлиять на нашу инфраструктуру. Например, если обнаружена уязвимость в межсетевых экранах Palo Alto, а мы используем продукты Check Point, эта уязвимость для нас неактуальна.
После того как составили список уязвимостей, мы начинаем оценивать их и определять приоритеты устранения. Уязвимости классифицируются как urgent — требующие немедленного устранения, critical, high, medium и low. Для каждой уязвимости разрабатываются рекомендации по устранению, которые могут включать обновление пакетов, установку патчей и последующую перезагрузку виртуальных машин. Затем создаются тикеты с назначением ответственных сотрудников и установлением Service Level Agreement (SLA) для устранения уязвимостей. После устранения проводится проверка эффективности принятых мер — либо повторное сканирование, либо тестирование командой пентестеров.
Завершающим этапом — анализ эффективности всего процесса и его улучшение. Мы оцениваем, все ли уязвимости удалось устранить, возникли ли какие-либо проблемы, соблюдались ли установленные SLA.
Безопасность разработки
Важно позаботиться о безопасности заранее, особенно при создании облачной платформы с нуля. Здесь нужно пройтись по следующим процессам:
— Security Design Review — анализ безопасности на этапе проектирования.
— Анализ кода на наличие уязвимостей и дефектов.
— Анализ компонентов и зависимостей.
— Тестирование на проникновение на этапах тестирования и пре-продакшн.
— Повышение осведомлённости разработчиков в вопросах безопасности.
Подробнее остановлюсь на двух процессах. Первый — Security Design Review. Когда команда разработки планирует создать новую функцию, мы оцениваем, требует ли она проверки с точки зрения безопасности. Если да, проводим анализ, выявляем потенциальные угрозы, после этого команда безопасности предлагает решения, как их устранить.
Второй процесс — анализ компонентов и зависимостей. Мы проверяем все используемые open-source-библиотеки, зависимости для различных языков программирования, образы из общедоступных реестров и финальный образ, который будет развёрнут в продакшене. Ищем возможные вредоносные программы, уязвимости и небезопасные практики, такие как dependency confusion.
Особое внимание уделяем проблеме dependency confusion. Разработчики, стремясь использовать последние версии пакетов или Docker-образов, часто используют тег latest. Злоумышленники могут воспользоваться этим, создавая вредоносные образы с очень высокими номерами версий, публикуя их в общедоступных реестрах. При автоматическом обновлении в процессе CI/CD эти вредоносные образы могут быть загружены вместо легитимных.
Для защиты от таких атак необходимо внедрять соответствующие меры в нашу платформу разработки. Эта практика крайне важна для обеспечения безопасности нашей инфраструктуры.
Как мы помогаем клиентам защищать данные
Мы рассмотрели, как нужно обеспечивать безопасность облака с точки зрения принципа Security by Design. Но облачная платформа — это не только инфраструктура, но и, что самое важное, — клиенты. Поэтому мы должны предоставить нашим клиентам такие сервисы безопасности, которые позволят им быть защищёнными.
К сожалению, в России всё чаще компании сталкиваются со взломом и хакерскими атаками. Например, недавно один крупный агрохолдинг столкнулся с серьёзной киберугрозой. Они долго боролись с последствиями, в то время как хакеры требовали выкуп в размере 70 биткоинов. По текущему курсу это около 6,3 миллиона долларов, или более 600 миллионов рублей, — сумма, сопоставимая с годовым бюджетом на информационную безопасность крупной организации, включая фонд оплаты труда.
Мы решили проверить ситуацию у наших клиентов и обнаружили в открытом доступе на GitHub логин и пароль администратора для VMware vCenter клиента. Мы использовали эти данные, проверили систему и уведомили клиента о том, что его пароль скомпрометирован и его необходимо изменить и не размещать учётные данные в открытом доступе. Вообще, это частая ситуация — секреты сохраняют прямо в коде и случайно выкладывают на GitHub. Мониторить и исправлять это — регулярная работа. Эта задача на стороне клиента, но и мы стараемся им с этим помочь.
Вместе с этим мы проанализировали открытые небезопасные порты на периметре сетей клиентов. Мы обнаружили множество открытых портов управления, таких как RDP, а также большое количество открытых портов SMB — это представляет потенциальную уязвимость. Кроме того, мы нашли 44 открытых порта, относящихся к системам управления базами данных, которые следует тщательно защищать, так как сами базы данных не так хорошо справляются с защитой, как специализированные средства. После такой проверки связались с клиентами и рекомендовали спрятать свои базы данных от прямого доступа из интернета.
Как облако помогает решать проблемы ИБ
Количество кибератак растёт, и они становятся всё более целенаправленными. Ситуация осложняется дефицитом на рынке труда специалистов по информационной безопасности и уходом западных вендоров с рынка. Российские производители работают над тем, чтобы заменить их, но решения пока не достигли того же уровня функциональности.
В этой ситуации облачный провайдер может помочь компаниям, потому что отсутствие должной информационной безопасности может буквально «убить» компанию, например, кибератака может вывести компанию из строя на недели.
Облако поможет не только защитить данные компании, но и решить проблему инвентаризации активов, с которой сталкиваются все отделы информационной безопасности. В облаке все активы автоматически инвентаризированы. Ещё мы проводим аттестацию нашей инфраструктуры, обеспечивая полное соответствие требованиям регулятора.
Провайдер может предоставить услуги консалтинга и пресейла, помогая спроектировать безопасный переход в облако по лучшим практикам информационной безопасности. Например, услуги SOC as a service для мониторинга и реагирования на инциденты, управление уязвимостями и патч-менеджмент, защиту от DDoS-атак и атак на веб-приложения.
Безопасность облачных систем требует комплексного подхода, который включает меры защиты физических дата-центров, постоянный мониторинг, своевременное обновление систем и готовность к быстрому реагированию на инциденты. Это непрерывный процесс, который требует внимания и адаптации к эволюционирующим угрозам в сфере кибербезопасности.
При этом нужно защищать не только облачную платформу, но и обеспечивать безопасность клиентов, поэтому облачные провайдеры должны предлагать комплексные решения, которые могут «спасти» компании от серьёзных последствий кибератак.
