Безопасность в облаках, или как проверить свои приложения на уязвимости
Егор Богомолов
Инженер защиты ИТ-инфраструктуры компании «Онсек»
Содержание:
- 1. О спикере
- 2. План вебинара
- 3. Преимущества облачных технологий
- 4. Зачем владельцу бизнеса облака?
- 5. Гарантии безопасности облачных платформ
- 6. Проблемы при миграции приложений в облако
- 7. Аудит безопасности облачных приложений
- 8. Новые угрозы
- 9. Обеспечение защищенности
- 10. Выводы
- 11. Вопросы и ответы
- 12. Запись вебинара
Хотели принять участие в вебинаре КРОК Облачные сервисы, но не нашли времени? Специально для таких случаев вводим новую рубрику в корпоративного блоге - материалы по мотивам наших онлайн-мероприятий. Первый из них - рассказ про особенности проведения аудитов в облачной среде.
О спикере
Меня зовут Богомолов Егор, я специалист по защите ИТ-инфраструктуры в компании «Валарм». Я занимаюсь всем, что связано с пентестами:
- анализом защищенности приложений, в т. ч. веб-приложений;
- собственно пентестами;
- анализом инфраструктуры;
- применением методов социальной инженерии и сопутствующими задачами.
«Валарм» имеет богатую экспертизу, я три года занимаюсь пентестами, более пяти лет работаю в ИТ и до сих пор увлечен всем, что связано с защитой ИТ-инфраструктуры.
План вебинара
Сегодня мы поговорим о том, с чем владельцы сервисов сталкиваются при миграции инфраструктуры (приложений, сервисов) в облако.
Также остановимся на том, как мы, пентестеры, реагируем на особенности работы приложений в облаках. Эта тема актуальна для тех, кто когда-либо сталкивался с аудитом в работе или хочет получить такую информацию для общего понимания. Следует знать, что пентест в облаке и в инфраструктуре заказчика очень сильно отличаются.
Обсудим мы и новые способы защиты в облаках. В конце подведем краткие итоги.
Преимущества облачных технологий
Почему будущее за облачными технологиями и почему уже сейчас множество приложений и сервисов переносят в облака? Это гибко, надежно и дешево.
Во-первых, отпадают расходы на «железо»: на покупку дорогостоящих серверов, компьютеров и т. д., поддержку, работу администраторов. Из-за ценового преимущества можно плавно масштабироваться от состояния, когда вашим приложением пользуется небольшое количество людей, к постепенному увеличению ресурсов.
Во-вторых, появляются новые инструменты управления. Они намного проще имеющихся инструментов, которые требуют обучения, опыта работы с ними, опыта конфигурации. О конфигурации облачных технологий и прочих средств мы поговорим отдельно.
В-третьих, делегируется процесс обслуживания «железа». Теперь его обслуживают и поддерживают в рабочем состоянии квалифицированные сотрудники, которых не все компании могут себе позволить.
В-четвертых, преимущество в удобстве масштабируемости — как бизнеса в целом, так и отдельных приложений и сервисов.
Зачем владельцу бизнеса облака?
Облака используют для:
- хранения данных (Dropbox, Mega и пр.);
- аренды мощностей, хостинга для сайтов, программ и т. д;
- управления бизнесом (платформы документооборота: 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 и пр.