Безопасность в облаках, или как проверить свои приложения на уязвимости

Меня зовут Богомолов Егор, я специалист по защите ИТ-инфраструктуры в компании «Валарм». Я занимаюсь всем, что связано с пентестами:

• анализом защищенности приложений, в т. ч. веб-приложений;
• собственно пентестами;
• анализом инфраструктуры;
• применением методов социальной инженерии и сопутствующими задачами.

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

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

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

Обсудим мы и новые способы защиты в облаках. В конце подведем краткие итоги.

Почему будущее за облачными технологиями и почему уже сейчас множество приложений и сервисов переносят в облака? Это гибко, надежно и дешево.

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

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

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

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

Облака используют для:

1. хранения данных (Dropbox, Mega и пр.);
2. аренды мощностей, хостинга для сайтов, программ и т. д;
3. управления бизнесом (платформы документооборота: Windows Live, G Suite).

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

Что хорошего в облачных платформах с точки зрения безопасности?

Облачные платформы смягчают часть рисков:

• Меньше ошибок конфигурации. Причина — удобный интерфейс облака. В отдельных случаях конфигурацию можно настроить по кнопкам, что позволяет сразу применять лучшие практики. Это удобнее, ведь не каждый администратор знает все тонкости работы с облаками. Разумеется, в облаке есть своя конфигурация, которая может на первый взгляд показаться незамысловатой, однако невнимательный подход к ней чреват последствиями.
• Оптимальное распределение ресурсов. Это улучшает точность, мощность и надежность приложений, а также их защищенность от угроз безопасности (DDoS-атак, ботов, большого трафика клиентов).
• Anti-DDoS. Большинство облачных провайдеров по умолчанию предоставляют сервисы для борьбы с DDoS-атаками.
• Борьба с ботами. Облачные сервисы часто предоставляют защиту от ботов, например, с помощью активации капчи (в частности, для ограничения парсинга данных в приложениях для продажи билетов).

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

Что следует предусмотреть при миграции в облако?

Неизвестные механизмы администрирования

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

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

В качестве примера можно привести недавнюю утечку данных 100 млн пользователей банка Capital One, ущерб от которой был оценен более чем в 140 млн долларов. Причина только в том, что администратор облака неверно настроил доступы для различных IAM-ролей. Злоумышленник — сторонний подрядчик — смог получить доступ к этим данным и украсть их.

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

Обновление ПО после миграции

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

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

Новые технологии виртуализации и оркестрирования

Сервис сервису рознь. Администраторы сталкиваются с новыми технологиями виртуализации и оркестрирования.

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

Угроза не самая значительная. Но нужно понимать, что и здесь могут тоже таиться риски безопасности, поэтому стоит пересмотреть подходы к миграции.

Безопасная реализация доставки

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

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

В облако же для удобства работы часто переносятся также многие сторонние звенья. Например, для поддержания управления доступом к приложению (коду, документации) появляются механизмы непрерывной доставки и тестирования CI/CD и т. д. Нужно понимать, что злоумышленнику теперь видны все звенья этой цепочки, и он волен выбирать, какое звено атаковать.

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

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

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

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

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

Во-вторых, больше нет доступа к инфраструктуре компании и DMZ-зоне. Раньше пентесты проводились так: мы пытались найти ваше приложение, скомпрометировать его и попасть в DMZ-зону или внутреннюю сеть. Теперь все усложняется. Мы изучаем, как правильно подсчитывать ресурсы. Если вы хотите провести аудит, нужно понимать, что в него включить, и это, в том числе, зависит от того, что находится в облаке. Это небольшая сложность, она не очень страшна для заказчиков, но для ведения проектов, для аудиторов это важный фактор.

Сейчас мы детальнее разберем угрозы безопасности, возникающие при работе с облаками.

Разграничение доступа

Какие пространства видите вы, когда используете мощности провайдера? Кто может видеть вас в этих пространствах? Владельцы редко получают доступ к сторонним приложениям, работая в облаке, но это все-таки случается даже с весьма крупными заказчиками. Скомпрометировав один узел, мы иногда можем скомпрометировать и остальные виртуальные узлы. Никому бы не хотелось, чтобы при компрометации слабо защищенного приложения пострадали и другие приложения, находящиеся в облаке.

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

Отказоустойчивость

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

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

Средства защиты

Выбор средств защиты ограничен. Не каждое средство защиты (Web Application Firewall, DLP, IDS и пр.) может работать в облаке. Некоторые средства доступны только в «железном» варианте, некоторые сложно установить в облако, и есть средства, которые в принципе не могут работать в облаках. Нужно заранее это учитывать и знать, можете ли вы перенести свое решение в облако.

Новые технологии оркестрирования и виртуализации

Мы уже говорили о том, что из-за новых технологий оркестрирования и виртуализации и появляются новые ошибки конфигурации (банк Capital One). Если в облаке предоставляется сырое управление средствами Docker, Kubernetes, дроплетами и т. д., появляются новые сложности, ведь администраторы должны иметь навыки работы с этими средствами и знать типовые ошибки в облачной инфраструктуре провайдера. Для этого нужно отслеживать инциденты, которые происходили с компанией. Полезно посмотреть, что происходило, разобраться в причине и пытаться не наступить на те же грабли. По-другому разобраться с этим вопросом практически невозможно.

Система разграничения в бакетах/подах/дроплетах и т. д.

Мы уже говорили о разграничении доступа между заказчиками, но есть еще разграничение доступа в ваши же сервисы. За этим тоже необходимо внимательно следить.

Сложность мониторинга состояния

Не каждый провайдер обеспечивает правильный мониторинг состояния, и приходится настраивать его самостоятельно. Предпочтительнее, когда провайдер дает возможность проводить максимально детальный мониторинг при помощи средств автоматизации (рассылки по электронной почте, СМС).

Сложности при расследовании инцидентов

В нашей практике также часто встречаются сложности при расследовании инцидентов с участием облачных провайдеров. Если что-то произошло в вашем облаке, вам нужно понять, что именно и как произошло. Для этого нужны правильно настроенные механизмы логирования со сроком длительности не менее 3–6 месяцев. Потеря логов при падении приложения недопустима.

Вы должны иметь возможность отследить, что происходило в облаке в любой момент времени. Об этом стоит позаботиться во время выбора провайдера, либо обеспечить это самостоятельно.

Теперь поговорим о том, как обеспечить защищенность. У нас есть облако и новые возможности — как же их применить?

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

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

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

Также желательно иметь хорошую систему защиты от DDoS-атак. Такая возможность есть сейчас во всех облаках.

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

Какие важные, явные и простые шаги следует предпринять при миграции в облако?

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

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

Обеспечьте мониторинг облачных сервисов на начальных этапах. Однажды это может сыграть важную роль в работе вашего приложения.

Какие инструменты вы используете? Как выстраиваете CI/CD? Как влияют проверки на процесс непрерывной поставки?

В «Валарм» используется постоянное сканирование периметра и собственное решение FAST для тестирования процессов CI/CD. Это сканер безопасности с постоянно пополняющимся набором детекторов для поиска типичных и новых уязвимостей приложений. 

Конечно, можно попытаться обойтись бесплатными или уже давно известными решениями, в данном случае мы говорим о динамическом анализе. К сожалению, не все хорошие популярные сканеры поддерживают удобную работу и запуск по событию. Порой приходится самостоятельно их настраивать. Мне не известно явного аналога продукта FAST на рынке, который бы включал в себя подобный сканер и работал с защищенностью приложений в процессе их поставки. Наши сканеры работают в облаке КРОК.

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