Orca Security - Безопасность публичных облаков 2022.

Введение.

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

Команда Orca Research Pod усердно исследует облачные продукты и сервисы, чтобы найти неизвестные уязвимости нулевого дня до того, как это сделают злоумышленники. До сих пор в этом году Orca объявила о пяти крупных уязвимостях в Azure и AWS и работала с поставщиками облачных вычислений и услуг над их устранением.

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

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

Ави Шуа, генеральный директор и соучредитель Orca Security

 

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

По прогнозам, тенденция перехода на облачные технологии будет развиваться и далее: по данным Gartner, общемировые расходы на публичные облачные сервисы будут расти с 20.4% в 2022 году (всего $494.7 млрд.) до более $600 млрд. в 2023.

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

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

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

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

Об исследовательской группе Orca

Orca Research Pod - это группа из 12 исследователей облачной безопасности с общим опытом работы в области кибербезопасности в 79 лет. Наша команда экспертов выявляет и анализирует облачные риски и уязвимости для укрепления платформы Orca Cloud Security Platform и продвижения передовых методов обеспечения безопасности облачных сред. Кроме того, исследовательская группа Orca обнаруживает и помогает устранять уязвимости в платформах облачных провайдеров, чтобы организации могли полагаться на безопасную инфраструктуру.

 

Исследователями Orca обнаружено и устранено 5 критических уязвимостей в AWS и Azure:

AWS Superglue.

• Критичность: Критическая.
• Дата обнаружения: 4 октября 2021.
• Время на устранение: 15 дней.
• Затронутый сервис: AWS Glue.

 

Azure AutoWarp.

• Критичность: Критическая.
• Дата обнаружения: 6 декабря 2021.
• Время устранения: 4 дня.
• Затронутый сервис: Azure Automation.

 

AWS BreakingFormation.

• Критичность: Критическая.
• Дата обнаружения: 9 сентября 2021.
• Время устранения: 26 часов.
• Затронутый сервис: AWS CloudFormation.

 

Azure SynLapse.

• Критичность: Критическая.
• Дата обнаружения: 4 января 2022.
• Время устранения: 5 месяцев.
• Затронутый сервис: Azure Synapse.

 

Databricks.

• Критичность: Высокая.
• Дата обнаружения: 12 декабря 2021.
• Время устранения: 3 часа.
• Затронутый сервис: Управляемое Databricks облачное хранилище.

 

Методология.

Команда Orca Research Pod составила этот отчет, проанализировав данные, полученные от миллиардов облачных активов в AWS, Azure и Google Cloud, просканированных платформой Orca Cloud Security Platform.

 

Набор данных для отчета:

• Данные о рабочих нагрузках и конфигурациях облачных сред.
• Миллиарды реальных «боевых» облачных активов.
• AWS, Azure и Google Cloud.
• Данные собраны в период с 1 января по 1 июля 2022 года.

Ключевые выводы.

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

 

• 36% организаций хранят незашифрованные конфиденциальные данные на своих облачных активах.

Почему это важно?

Шифрование конфиденциальных данных значительно снижает вероятность их непреднамеренного раскрытия и может свести на нет последствия взлома, если шифрование останется невскрытым.

 

• 78% выявленных атак используют известные уязвимости (CVE) в качестве вектора для первоначального доступа.

Почему это важно?

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

 

• 7% организаций имеют выходящие в Интернет устаревшие активы с открытыми портами.

Почему это важно?

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

 

• Средней атаке требуется всего 3 шага, чтобы добраться до критичных активов.

Почему это важно?

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

 

• 33% организаций имеют корневую учетную запись облачного провайдера без многофакторной аутентификации.

Почему это важно?

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

 

• 72% имеют по крайней мере один S3 Bucket, к которому разрешен публичный доступ READ.

Почему это важно?

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

 

• У 12% рабочих сред с доступом в Интернет есть хотя бы один слабый или скомпрометированный пароль.

Почему это важно?

Это простой способ для хакеров получить доступ к вашей облачной среде.

 

• У 70% сред есть публично доступный сервер API Kubernetes.

Почему это важно?

Это делает сервер API Kubernetes уязвимым для попыток разведки и потенциальных атак нулевого дня.

 

• 58% имеют бессерверную функцию AWS Lambda или функцию Google Cloud с неподдерживаемыми исполняемыми процедурами.

Почему это важно?

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

 

• В среднем организациям требуется 18 дней для устранения предупреждения мониторинга о «неминуемой угрозе».

Почему это так важно?

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

Ваш «бастион» в облаке.

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

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

 

Рис. 1: Типы облачных приложений.

Поддержка и обслуживание.

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

 

Уязвимости.

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

• Мы обнаружили, что 10% организаций имеют уязвимости, которые были опубликованы более 10 лет назад.
• В среднем мы обнаружили, что информационные активы (виртуальные машины, контейнеры и образы) имеют не менее 50 известных уязвимостей (CVE) за один год.
• Важно устранять серьезные уязвимости как можно быстрее, поскольку это, безусловно, самый распространенный начальной вектор кибератак (78%).

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

 

Log4Shell.

В декабре 2021 года мир кибербезопасности потрясло обнаружение серьезной уязвимости нулевого дня в Apache Log4j, вездесущем инструменте протоколирования, включенном почти в каждое Java-приложение.

Уязвимость была проста в эксплуатации, позволяла выполнять удаленный код без проверки подлинности (RCE) и получила название «Log4Shell».

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

Перенесемся в середину 2022 года. За последние 6 месяцев большинство организаций неистово исправляли уязвимости Log4j. Однако мы по-прежнему видим, что Log4Shell жив и здоров во многих облачных средах:

• Почти 5% ресурсов все еще имеют хотя бы одну из уязвимостей Log4j , из которых 10,5% имеют выход в интернет.
• 30% уязвимых Log4j ресурсов, обнаруженных в период с декабря 2021 года по январь 2022 года, остаются неустраненными, из них 6,2% потенциально раскрывают персональные данные клиентов.
• Подавляющее большинство (68%) уязвимостей Log4j обнаружено на виртуальных машинах. Также по-прежнему довольно много их в контейнерах и образах контейнеров. Образы представляют особую проблему, поскольку эти уязвимости будут воспроизводиться при каждом использовании.

 

Рис. 2: Уязвимые к Log4Shell активы.

 

Примечание: Когда мы упоминаем уязвимости Log4j, мы имеем в виду следующие CVE: CVE-2021-44228, CVE-2021-4104, CVE-2021-45046 и CVE-2021-45105.

 

Устаревшие активы.

Устаревший актив - это облачный актив, который использует неподдерживаемую операционную систему (например, CentOS 6, Linux 32-bit или Windows Server 2012) или остается без исправлений в течение 180 дней или более.

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

 

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

• В среднем 11% активов организаций устарели, а 10% организаций имеют более 30% рабочих нагрузок в устаревшем состоянии с точки зрения безопасности.
• 19% выявленных путей атаки используют устаревшие активы в качестве вектора начального доступа.
• У 7% организаций есть устаревшие активы, выходящие в Интернет, с открытыми портами 80, 443, 8080, 22, 3389 или 5900. Это особенно опасно, поскольку хакеры постоянно сканируют открытые порты на известные уязвимости. Это эквивалентно тому, как если бы вы оставили входную дверь открытой, а затем поставили в доме сейф со сломанным замком.
• Из всех устаревших активов большинство - контейнеры, и почти половина работает под управлением неподдерживаемых версий Alpine OS.

 

Рис. 3:

 

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

Гигиена облака.

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

 

Неиспользуемые учетные данные.

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

• Из всех проверенных организаций с AWS-средой 76% имели учетные данные, которые не использовались в течение 90+ дней.

 

Многофакторная аутентификация.

Для предотвращения перехвата учетных данных всегда рекомендуется использовать многофакторную аутентификацию (MFA).

• 33% имеют корневую учетную запись облачного провайдера AWS без MFA. Это очень рискованно, поскольку учетная запись root является наиболее привилегированным пользователем в облачном аккаунте.
• Почти в половине сред AWS имеется как минимум одна роль, которая позволяет осуществлять кросс-аккаунт доступ без внешнего ID или MFA, что не только увеличивает вероятность несанкционированного доступа, но и расширяет сферу доступа пользователей, которые могут быть скомпрометированы.
• У 58% отключен MFA хотя бы для одного привилегированного пользователя в Azure.

 

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

 

Принцип наименьших привилегий.

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

• 44% сред имеют хотя бы одну привилегированную роль управления доступом к идентификационным данным (IAM). Если злоумышленник завладеет привилегированными учетными данными IAM, он не только получит доступ к системе, но и сможет остаться незамеченным. Активируя привилегированный доступ только на то время, когда он необходим, можно значительно сократить поверхность атаки.
• 71% используют учетную запись службы по умолчанию в Google Cloud. Это не рекомендуется, поскольку эта учетная запись по умолчанию предоставляет права редактора, что не соответствует PoLP.
• 42% просканированных облачных сред предоставляют административные разрешения более чем 50% пользователям организации.
• 41% организаций имеют роль, которая может быть принята внешней сущностью, что может быть использовано злоумышленниками для компрометации ваших облачных ресурсов. Рекомендуется всегда использовать внешние идентификаторы и/или MFA при предоставлении доступа внешним идентификаторам.

 

Время устранения последствий.

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

 

Время на на устранение предупреждений категории «Неминуемая угроза»:

• Аутентификация - 6 дней.
• Неправильная конфигурация сети - 25 дней.
• Данные под угрозой - 13 дней.
• Вредоносная активность - 7 дней.
• Неправильная конфигурация IAM - 22 дня.
• Устаревшие активы - 27 дней.
• Лучшие практики - 13 дней.
• Уязвимости - 23 дня.
• Латеральное перемещение - 47 дней.

 

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

Ошибки при строительстве

Независимо от того, как часто проводится обучение и насколько хорош ИТ-специалист, в той или иной степени человеческие ошибки неизбежны. На самом деле, по прогнозам Gartner, до 2025 года более 99% инцидентов в облаке будут происходить из-за предотвратимых неправильных конфигураций или ошибок конечных пользователей. Здесь мы перечислили три основные ошибки конфигурации облака, которые мы наблюдаем в средах наших клиентов.

 

Топ неправильных конфигураций №1: неправильные конфигурации ключей AWS.

Сервис управления ключами AWS (KMS) позволяет администраторам создавать, удалять и контролировать ключи, которые шифруют данные, хранящиеся в базах данных и продуктах AWS.

• 8% сконфигурировали ключ KMS с политикой публичного доступа. Это особенно опасно, поскольку создает легкий вектор атаки для злоумышленников.
• 99% используют как минимум один ключ KMS по умолчанию. Всегда рекомендуется использовать ключи, управляемые клиентом, вместо управляемых AWS.
• У 80% отключена ротация KMS. Лучше включить ротацию для всех главных ключей KMS, чтобы снизить вероятность того, что злоумышленник использует ключ без вашего ведома.

 

Топ неправильных конфигураций №2: неправильные конфигурации политики и доступа.

• 80% имеют пользователя с встроенной политикой и 49% имеют группу с встроенной политикой. Настоятельно рекомендуется использовать IAM-группы для управления разрешениями вместо использования встроенных или непосредственно подключенных политик, поскольку это снижает вероятность того, что пользователь или группа случайно получит или сохранит чрезмерные привилегии.
• 79% имеют как минимум один ключ доступа старше 90 дней. Лучшей практикой является настройка ротации ключей доступа старше 90 дней, чтобы ограничить время, в течение которого скомпрометированный набор ключей доступа IAM может потенциально предоставить доступ к вашей учетной записи AWS.
• 51% имеют корзину Google Storage без доступа на уровне корзины. Если уровни доступа установлены неравномерно, это означает, что злоумышленник может сместиться в сторону и получить более высокий уровень доступа.

 

Топ неправильных конфигураций №3: неправильные конфигурации баз данных

• У 75% отключен AWS MultiAZ. Если Multi-AZ включен и основной узел выходит из строя, он автоматически переходит на одну из копий для чтения, что позволяет избежать простоя системы.
• У 77% по крайней мере один экземпляр базы данных RDS использует порты по умолчанию, и 42% из них выходят в Интернет. Лучшей практикой является изменение портов баз данных RDS, поскольку если потенциальный злоумышленник не знает, какие порты вы используете, это значительно затрудняет попытки разведки.
• 42% облачных сред Google не используют автоматическое резервное копирование

«Ключи к королевству»

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

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

• 18% имеют как минимум одну рабочую нагрузку, выходящую в Интернет, со слабым или скомпрометированным паролем.
• 43% имеют хотя бы один пароль в открытом виде в истории командной строки Linux, доступной через Интернет. На взломанной системе злоумышленники будут искать в файле истории bash учетные данные и другую полезную информацию.
• 56% организаций на AWS, 11% организаций на Azure, 55% организаций на GCP имеют чувствительные ключи на своей системе. Это плохая практика, так как если злоумышленник получит доступ к этим ключам, они могут быть использованы для доступа к конфиденциальным ресурсам и выполнения несанкционированных операций.
• 21% имеют как минимум одну рабочую нагрузку, выходящую в Интернет, с некорпоративным ключом аутентификации. Нелегально добавленные ключи обычно содержат некорпоративные имена пользователей и адреса электронной почты, поэтому их следует проверить и удалить.

Дорога за вратами.

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

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

• Незащищенный закрытый ключ: Если закрытые ключи обнаружены, они могут быть использованы вместе с открытым ключом для бокового перемещения.
• Настройки групповой политики с cpassword: Cpasswords зашифрованы с помощью слабого алгоритма шифрования, который можно легко расшифровать. После расшифровки cpassword может быть использован для латерального перемещения.
• Чувствительные ключи AWS, ключи Azure или учетные данные GCP в системе: Если эти ключи или учетные данные получены злоумышленником, они могут быть использованы для доступа к конфиденциальным ресурсам и выполнения несанкционированных операций.
• Пароль в истории командной строки: На взломанной системе злоумышленники будут искать в файле истории bash учетные данные и другую полезную информацию.
• Повышение привилегий IAM: Атакующий с этим правом может повысить свои привилегии, создав или обновив встроенную политику для роли, к которой имеет доступ.

Защита «сокровищ».

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

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

• 36% организаций хранят незашифрованные конфиденциальные данные, такие как секреты и персональные данные, в файлах, корзинах хранения, контейнерах и бессерверных средах. Шифрование конфиденциальных данных значительно снижает вероятность их непреднамеренного раскрытия и может свести на нет последствия взлома, если шифрование не будет вскрыто.
• 35% имеют хотя бы одну рабочую нагрузку с выходом в Интернет с конфиденциальной информацией в Git-репозитории. Киберпреступники могут легко извлечь эту информацию и использовать ее для компрометации ваших систем.
• 6% неустраненных уязвимостей Log4j, обнаруженных в период с декабря 2021 по январь 2022 года, потенциально раскрывают персональные данные.

Маршруты атаки.

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

 

Основные начальные векторы атак.

Подавляющее большинство атак начинается с использования уязвимости. На уязвимые активы приходится почти пятая часть векторов атак.

 

Рис. 4: Последовательность кибератаки.

 

Шаги на маршруте атаки.

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

Например, в приведенном выше маршруте атаки:

• Начальным вектором атаки является экземпляр EC2 с уязвимостью сервиса, которая позволяет скомпрометировать актив.
• На этом активе также имеется незащищенный закрытый ключ, который позволяет получить доступ к активу «Dev Server», что может быть использовано злоумышленником для латерального перемещения.
• Получив доступ к активу «Dev Server», злоумышленник может получить роль администратора, которая позволяет получить доступ ко всей среде.

 

Рис. 5: Самые популярные первичные векторы атак.

 

Конечные цели и задачи.

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

 

Рис. 6: Популярные цели и задачи атак.

Основные компоненты облачной среды.

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

 

Хранилища.

Примерами облачных сервисов хранения данных являются корзины AWS Simple Storage Services (S3), Azure Blob storage и корзины Google Storage. Рекомендуется шифровать хранимые данные и регулярно выполнять резервное копирование для защиты от атак шифровальщиков. Поскольку в хранилищах часто содержатся важные для бизнеса или конфиденциальные данные, важно также обеспечить их безопасную конфигурацию. К сожалению, мы обнаружили, что слишком часто банальные ошибки в конфигурации хранилища оставляют дверь открытой для утечки данных и атаками вымогателей:

• 72% сред AWS имеют по крайней мере один S3 Bucket, который предоставляет публичный доступ READ. Даже если S3 не содержит конфиденциальных данных, все равно рекомендуется держать все корзины в настройках «private» по умолчанию, поскольку другой член команды может случайно сохранить конфиденциальные данные в этом хранилище, не понимая, что оно настроено на публичный доступ READ.
• 42% организаций, использующих Azure, имеют как минимум один общедоступный контейнер blob. Однако только 2,5% активов Azure Blob Storage находятся в открытом доступе. Обратите внимание, что несанкционированный доступ к контейнерам Azure гораздо сложнее осуществить, чем к корзинам S3, поскольку необходимо знать уникальное имя учетной записи хранилища, имя самого контейнера, прежде чем вы сможете пытаться получить доступ.
• 39% облачных сред Google имеют хотя бы один общедоступный блок хранения  Google. Как и в случае с публично доступными корзинами S3, это означает, что злоумышленнику будет легко получить доступ к данным.

 

Базы данных.

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

• 60% не шифруют снапшоты экземпляров баз данных, что означает, что они легко читаются потенциальным злоумышленником.
• 67% требуют только пароль и имя пользователя для доступа к базе без использования аутентификации IAM, что делает их уязвимыми для атак методом перебора и по словарю.
• 2% используют имя пользователя AWS по умолчанию для своего сервиса реляционных баз данных Amazon Relational Database Service (RDS). Используя имя пользователя по умолчанию, потенциальному злоумышленнику нужно только угадать пароль, что можно сделать с помощью перебора.
• 73% не используют службы протоколирования для своих баз данных. Рекомендуется включить ведение журнала в целях безопасности и устранения неполадок.

 

Виртуальные машины.

Виртуальные машины (ВМ) - это вычислительные ресурсы, которые имитируют физические машины, запуская отдельную систему с собственной ОС и приложениями. Для обеспечения безопасности ВМ важно знать, что запущено на экземплярах ВМ (ОС, программное обеспечение и т.д.) и что они свободны от уязвимостей. Также важно обеспечить регулярную проверку образов ВМ на наличие уязвимостей. Поскольку образы используются для создания новых виртуальных машин, любые уязвимости будут автоматически плодиться при копировании образов для создания новых виртуальных машин.

• 71% сред Google Cloud имеют экземпляр ВМ с учетной записью сервиса по умолчанию, которую хакер может использовать для перемещения между экземплярами вычислительных машин.
• 23% имеют по крайней мере один экземпляр EC2 с доступом в Интернет, который имеет полный доступ к S3. Это очень опасно, так как если EC2 будет взломан, все корзины S3 будут открыты для злоумышленника.
• 23% имеют как минимум один экземпляр EC2 с правами администратора. Это означает, что если EC2 скомпрометирован, это потенциально может привести к полному захвату облачной среды.
• 32% имеют по крайней мере один экземпляр GCP Compute Engine с доступом к Интернету и широкими правами на чтение хранилища, что не соответствует принципу наименьших привилегий.

 

Контейнеры.

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

• 16% контейнеров находятся в устаревшем состоянии, что означает, что они используют неподдерживаемую операционную систему или остаются без исправлений в течение 180 дней и более.
• 84% имеют как минимум один контейнер с критической DoS-уязвимостью Open SSL infinite loop (CVE-2022-0778)
• 28% имеют как минимум один контейнер с уязвимостью Spring4Shell (CVE-2022-22965 RCE)
• 17% имеют как минимум один контейнер с критической уязвимостью Samba RCE (CVE-2021-44142).

 

Kubernetes.

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

• 62% контейнеров оркеструются устаревшей версией Kubernetes.
• У 70% сервер Kubernetes API находится в открытом доступе. Это делает сервер Kubernetes уязвимым для попыток разведки и потенциально для атак нулевого дня.
• У 30% есть контроллер подсистем с ролью, позволяющей создавать или изменять другие подсистемы. Это может позволить злоумышленнику закрепиться на начальном этапе и облегчить латеральное перемещение злоумышленника.

 

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

 

Бессерверная архитектура.

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

• У 69% есть хотя бы одна бессерверная функция, раскрывающая секреты в переменной окружения. Это означает, что существуют ключи, токены авторизации или пароли, которые могут быть получены злоумышленниками.
• У 37% есть хотя бы одна бессерверная функция с привилегиями администратора. В соответствии с Принципом наименьших привилегий (PoLP), рекомендуется предоставлять функциям только те разрешения, которые необходимы для выполнения их задач.
• 58% имеют функции AWS Lambda или Google Cloud с неподдерживаемым runtime, что аналогично использованию неподдерживаемой ОС на виртуальной машине. Неподдерживаемый runtime означает, что он больше не исправляется и не поддерживается облачным провайдером, что подвергает функцию многочисленным рискам.

Рекомендации.

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

 

Придерживайтесь принципа наименьших привилегий:

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

 

Ликвидируйте неиспользуемые активы:

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

 

Определите критически важные активы:

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

 

Шифруйте конфиденциальные данные и ключи:

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

 

Проводите регулярные аудиты:

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

 

Патчи, патчи, патчи:

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

 

Применяйте MFA и надежное управление паролями:

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

 

Выполняйте резервное копирование:

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

 

Ведите инвентаризацию облачных активов:

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

 

Защитите шаблоны и изображения:

Убедитесь, что шаблоны Infrastructure as Code (IaC) и образы контейнеров проверяются на наличие неправильных конфигураций и других рисков, чтобы предотвратить миграцию уязвимостей в боевые среды.

 

Используйте чеклисты:

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

О компании Orca Security.

Orca Security - это ведущая в отрасли безагентная платформа облачной безопасности, которая выявляет и устраняет риски и проблемы, связанные с соблюдением нормативных требований, в облачных средах AWS, Azure, Google Cloud и Kubernetes. Вместо наложения нескольких изолированных друг от друга инструментов или развертывания громоздких агентов, Orca обеспечивает полную безопасность облака через единую платформу, сочетая два революционных подхода: SideScanning, который обеспечивает беспрепятственное и полное покрытие без необходимости устанавливать агенты, и Unified Data Model, которая позволяет централизованно проводить контекстный анализ всего облачного массива.

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

 

Источник: https://orca.security