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

Неправильные конфигурации

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

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

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

Незащищенные API

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

Недостаточная видимость и обнаружение угроз

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

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

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

Неправильное понимание «модели общей ответственности» (т. е. угроз во время выполнения)

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

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

Теневые ИТ

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

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

Отсутствие комплексной стратегии облачной безопасности

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

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

Лучшие практики безопасности облачных приложений

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

1. Сосредоточьтесь на противнике

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

Разница в том, что облако предлагает злоумышленникам возможность использовать новый набор тактик, методов и процедур (TTP).

2. Уменьшите риск воздействия

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

Существует два основных способа снизить риск заражения:

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

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

3. Разработайте и внедрите политику, структуру и архитектуру облачной безопасности.

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

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

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

4. Отслеживайте поверхность атаки

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

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

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

После тщательного исследования эксперты предположили, что злоумышленник, вероятно, извлек имена корзин S3 из выборочных данных DNS-запросов, которые собрал из нескольких общедоступных каналов. Этот тип данных легко получить, получив доступ к ресурсам через общедоступный Wi-Fi. Урок здесь заключается в том, что злоумышленник иногда имеет больше знаний и информации об облачном следе организации, чем вы думаете.

Важно отметить, что не только вредоносное ПО и вирусы влияют на работу сайта, а и многие другие факторы. Но, какова бы ни была причина, по которой страница сайта не открывается, например проблемы с базой данных или сервером, DDoS-атаки или вирусы, важно контролировать доступность сайта для посетителя. Ситуация, при которой пользователь не может открыть страницу вашего сайта, отрицательно влияет на поднятие сайта в поиске (поисковой выдаче) и оставляет негативное впечатление о вашем сайте у посетителя. Вы теряете потенциальных клиентов, а значит и деньги. Используйте хороший сервис, например BAILRY для постоянного контроля (проверки) доступности сайта. Сервис предоставляет как бесплатную регулярную (периодическую) проверку доступности сайта, так и платную услугу - для постоянного контроля доступности сайта.

Компания Mainton - разработка и тестирование программного обеспечения под заказ, SEO и реклама в интернете с 2004 года.