Топ-11 угроз безопасности облачных сервисов

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

Вот эти 11 угроз в порядке убывания важности:

1. Недостаточное управление идентификацией, полномочиями, доступом и паролями

Заботы об идентификации и доступе занимают ведущее место в умах ИБ-профессионалов, согласно данным отчета CSA. “Доступ возглавил список в этом году, потому что с него начинается и им заканчивается защита данных», - говорит Йео.

Ключевые выводы об управлении доступом и идентификацией в отчете включают:

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

2. Небезопасные интерфейсы и API

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

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

Ключевые выводы об API включают:

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

3. Мисконфигурация и неадекватный контроль изменений

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

Ключевые выводы о мисконфигурациях и неадекватном контроле изменений включают:

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

4. Недостатки архитектуры и стратегии облачной безопасности

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

Ключевые выводы о недостатках безопасности облачной архитектуры и дизайна включают:

• Компаниям стоит рассматривать бизнес-цели, риск, угрозы безопасности и соответствие закону в облачных сервисах и дизайн-решениях инфраструктуры.
• Учитывая высокий темп изменений и ограниченный централизованный контроль в облачных хранилищах более важно развивать и адаптировать инфраструктурную стратегию и принципы дизайна.
• Адаптируя решение, стоит принять во внимание фундаментальные практики оценки безопасности вендором. Они должны включать дизайн безопасности и интеграции, чтобы избежать системных провалов, которые имели место в уязвимостях SolarWinds, Kaseya и Bonobos.

5. Небезопасная разработка приложений

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

Ключевые выводы по небезопасной разработке приложений:

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

6. Небезопасные ресурсы третьей стороны

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

Ключевые выводы о небезопасных ресурсах третьих сторон выглядят следующим образом:

• Нельзя предотвратить уязвимости в коде или продуктах, которые не создавал, но можно принять взвешенное решение о том, какой продукт использовать. Стоит искать продукты, которые имеют официальную поддержку. Выбора достойны сертифицированные решения, которые подтверждают усилия в направлении безопасности, имеют программу вознаграждения нашедших уязвимости и ответственно подходят к своим пользователям, быстро сообщая о проблемах безопасности и выпуская обновления.
• Идентифицируйте и отслеживайте продукты третьих сторон, которыми пользуетесь. Будет неприятно обнаружить, что используется уязвимый продукт, только после того, как будет опубликован список жертв. Это включает open source продукты, облачных провайдеров и управление услугами, а также интеграции, которые могут быть добавлены в ваше приложение.
• Стоит периодически проверять ресурсы третьих сторон. Если обнаружатся продукты, которые не нужны, удалите их, отзовите доступ и любые разрешения, которые могли быть выданы им в кодовом хранилище, инфраструктуре и приложениях.
• Чтобы не стать слабым звеном, нужно периодически проводить пентестинг своего приложения, обучать разработчиков безопасному кодированию, использовать решения статического и динамического тестирования безопасности приложения.

7. Системные уязвимости

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

О системных уязвимостях в отчете были сделаны следующие выводы:

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

8. Случайное раскрытие облачных данных

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

Отчет включает следующие выводы по раскрытию облачных данных:

• Какие базы данных в облачных сервисах? Проверьте базы данных PaaS, хранилища и базы данных хостинга, включая виртуальные машины, контейнеры и установленное на них ПО.
• Что эффективно выделять из облачной среды? Выбирайте поисковые машины, которые полностью прозрачны в облачной среде, чтобы идентифицировать любые корневые или сетевые сервисы, которые позволяют трафику быть видимым извне. Это включает балансировщики загрузок, сети доставки контента, сетевой пиринг и облачные файерволы.
• Поисковая машина должна учитывать множество сетевых компонентов, включая кластерные IP, услуги Kubernetes и правила входа.
• Следует сократить доступ, убедившись, что базы данных конфигурируются с помощью менее привилегированной политики контроля доступа, а все назначения полномочий контролируются.

9. Мисконфигурация и эксплуатация бессерверных и контейнерных загрузок

Управление и масштабирование инфраструктуры запуска приложений по-прежнему может вызывать сложности у разработчиков. Им нужно проявлять больше ответственности в отношении контроля сети и безопасности своих приложений.

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

Ключевые выводы по мисконфигурации и эксплуатации бессерверной и контейнерной загрузок такие:

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

10. Организованные преступления, хакеры и группировки

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

Ключевые выводы по этому разделу сформулированы следующим образом:

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

11. Эксфильтрация данных облачных хранилищ

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

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

Ключевые выводы об эксфильтрации облачных хранилищ звучат сформулированы следующим образом:

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

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

Смещая фокус на облачную безопасность

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

Автор: John P. Mello Jr.