В облачных средах нет периметров, есть ошибки конфигурации, избыточные привилегированные роли и небезопасные API, которые только и ждут, чтобы их обнаружили. В отличие от традиционной инфраструктуры, угрозы здесь не заявляют о себе. Кроме того, совсем недавний пример уничтожения этой инфраструктуры целыми дата-центрами, заставляет задуматься об операционной возможности применения. Множество металлообрабатывающих производств, выполняющих госзаказы (в том числе для ВПК), не допускают даже перевод средств управления производством в облачные среды, не говоря уже о бухгалтерии (спецсчета отчётности), документации госприёмки, чертежах конструкторских бюро и т.п. Несомненно, что им приходится принимать дополнительные меры защиты локальной сети от внешнего интернета, связывая станки ЧПУ для токарной или фрезерной обработки.
Да, облачные технологии существенно изменили традиционные методы развёртывания приложений, хранения данных и управления ИТ-инфраструктурой. Хотя произошедшие изменения феноменальны, возникшие в связи с ними трудности показывают пугающую историю — 82% случаев утечки данных связаны с информацией, хранящейся в облаке, и неправильной конфигурацией. Этот фактор по-прежнему остаётся основной причиной этих инцидентов. Кроме того, на выявление и устранение таких утечек требуется в среднем 277 дней.
На практике тестирование на проникновение в облачную среду подразумевает этичный взлом собственной облачной среды для выявления уязвимостей в системе безопасности. В отличие от традиционных аудитов безопасности, оно не опирается на контрольные списки и проверку конфигурации. Процесс включает в себя активные попытки прорвать защиту облачных сервисов. Для этого используются имитационные методы, реализуемые в реальном времени для доступа к хранилищам S3, повышения привилегий за счёт неправильно настроенных ролей IAM, эксплуатации уязвимых API или перемещения по облачным ресурсам. Хотя сфера применения тестирования на проникновение в облачные среды вполне ясна, возникает вопрос: зачем оно вообще нужно?
Компании сталкиваются с уникальным и постоянно меняющимся ландшафтом попуток хакерской атаки. Последние данные показывают, что 80% организаций столкнулись как минимум с одним инцидентом в год, а сами сервисы, предоставляющие эти услуги, подвергались, в среднем, 1925 кибератакам за неделю. Понимание этих угроз имеет важное значение для эффективного тестирования на проникновение и управления уровнем безопасности. Основные проблемы возникают из-за неправильной настройки и, что тревожно, 82% этих ошибок связаны с человеческим фактором, а не с дефектами программного обеспечения. К числу наиболее распространённых сценариев неправильной настройки относятся:
1.) Часто в открытых хранилищах неправильно настроены права доступа. Недавние исследования показывают, что в 72% облачных сред общедоступные базы данных не имеют достаточных средств контроля доступа.
2.) Многие организации развёртывают облачные ресурсы с конфигурациями по умолчанию, в которых доступность ставится выше безопасности. Учётные данные по умолчанию, открытые сетевые порты и отключённые параметры шифрования создают непосредственные уязвимости.
3.) В облачных средах часто используются виртуальные машины или ПО не предназначенное для серверного использования, содержащие конфиденциальные данные. Неправильно настроенные группы безопасности, списки контроля доступа к сети (ACL) и правила брандмауэра часто позволяют беспрепятственно входить в облачную экосистему из интернета.
Интерфейсы прикладного программирования (API) служат основой облака, но при неправильной защите они также представляют собой значительное поле деятельности для совершения атак. Публично доступные API-интерфейсы и отсутствие шифрования при обмене данными через API создают множество точек входа для злоумышленников. Это приводит к несанкционированному доступу к функциям, что может поставить под угрозу всю инфраструктуру.
Неправильная настройка в системах управления идентификацией и доступом (IAM) позволяет хакерам получать несанкционированный доступ, повышать привилегии и перемещаться по облачной инфраструктуре горизонтально. Исследование показывает, что 54% данных, хранящихся в облаке, классифицируются, как конфиденциальные, однако только 8% респондентов шифруют 80% или более своих облачных данных. Данные, хранящиеся в базах данных, объектных хранилищах и файловых системах, часто не имеют необходимого шифрования, что делает их уязвимыми. Кроме того, передача данных между облачными сервисами при отсутствии (или слабо защищённой конфигурации) протокола Transport Layer Security (TLS) делает их привлекательными для перехвата извне.
Для эффективной защиты необходима прозрачность процессов на удалённых серверах. Однако 35% специалистов по безопасности называют недостаточную прозрачность и контроль на этапе разработки, одними из факторов, способствующих возникновению рисков. Без постоянного мониторинга инциденты остаются незамеченными в течение длительного времени. Это дает злоумышленникам возможность не только для кражи данных, но и закрепления в системе. Это приводит к тому, что критически важные события в сфере безопасности остаются незарегистрированными, журналы аудита — неполными, а также создаёт препятствия для проведения расследования по обнаружению внедрения и нанесённому урону. Более того, такие работы требуется проводить с защищённого ПК с АПМДЗ — дабы предотвратить проникновение хакера в систему управления ещё и локальной сетью организации.
Широкий спектр угроз и уязвимостей уже оправдывает необходимость в надёжном механизме, выходящем за рамки автоматизированных сканеров. Более того, острая необходимость в нем также обусловлена пробелами в традиционных методологиях тестирования на проникновение, которые были разработаны для предсказуемых, статичных сред с чёткими границами и периметрами. Службы безопасности могли составить карту каждого актива, контролировать каждую конфигурацию и определить явные сетевые периметры. Сейчас эта процедура требует принципиально иного подхода. Динамичный характер облачной инфраструктуры включает в себя общедоступные хранилища данных, чрезмерно либеральные политики идентификации для небезопасных API и сложные контейнерные архитектуры. Более того, модель разделённой ответственности и сложность политик управления доступом создают уникальные нестандартные проблемы, которые традиционные методы просто не могут решить.
Новые типы методологий адаптируются к динамичному, распределённому характеру облачной инфраструктуры, сохраняя при этом строгость и тщательность. Процесс начинается с получения необходимого доступа к данным и разрешений от поставщиков облачных услуг. Несанкционированное тестирование на этом этапе может вызвать срабатывание систем безопасности, нарушить условия предоставления услуг или привести к блокировке учётной записи. Параллельно команды определяют область применения, выявляя, какие облачные ресурсы, регионы и сервисы включены, а также устанавливая чёткие границы для проведения тестирования. Далее специалистами оценивается, чего может добиться злоумышленник после первоначального взлома. Тестировщики анализируют потенциальные пути горизонтального перемещения, выявляют риски утечки конфиденциальных данных и оценивают эффективность механизмов мониторинга и обнаружения, раскрывая истинное влияние обнаруженных уязвимостей на бизнес.
Тестирование на уровне приложений изучает, как специфические функции и конфигурации влияют на безопасность приложений. В отличие от традиционного процесса, тестирование облачных приложений учитывает бессерверные архитектуры, контейнерные развертывания, облачную аутентификацию и конфигурации шлюзов API. Тестирование безопасности инфраструктуры, как кода (IaC) проверяет шаблоны и скрипты автоматизированного развертывания до того, как они будут предоставлять облачные ресурсы.
Тестировщики анализируют конфигурации Terraform, шаблоны CloudFormation и манифесты Kubernetes на предмет предварительного присутствия уязвимостей в системе безопасности. Кроме того, они проверяют, как скрипты автоматизации обрабатывают учётные данные, подтверждают корректность средств контроля безопасности, определённых в коде.
По мере того, как организации продолжают переносить критически важные системы и конфиденциальные рабочие нагрузки в облако, потребность в тщательном и регулярном тестировании возрастает. Облачные среды быстро расширяются и меняются, открывая доступ к новым сервисам, идентификаторам и путям атак.
