Skip to content
RiverCore
ShutterGap: Почему ежедневные проверки CSPM пропускают 99% утечек AWS-снимков
CSPM AWS snapshotscloud securityRDS snapshot leakdaily CSPM scans miss snapshot exposuresAWS RDS public snapshot detection gap

ShutterGap: Почему ежедневные проверки CSPM пропускают 99% утечек AWS-снимков

2 авг 20267 мин. чтенияAlex Drover

Каждый, кто дежурил по AWS-инфраструктуре, знает тихий ужас от слов «публичный снимок». Новое исследование ShutterGap компании Aryon Security говорит, что проблема хуже, чем показывают дашборды: 20% публично доступных снимков RDS видны менее двух минут, а 99% удалённых снимков RDS и DocumentDB исчезают в течение 30 минут после создания. Если ваш CSPM работает в ежедневном цикле, он фактически слеп к большинству реальных событий утечки.

Цифры

Ключевой вывод, о котором сообщил CyberSecurityNews, — это временной разрыв между скоростью, с которой AWS-ресурсы мелькают в публичном доступе, и медлительностью большинства инструментов безопасности. За одно 90-минутное окно наблюдения в регионе us-east-1 количество публично доступных снимков RDS изменилось 12 раз. Шесть появились. Шесть исчезли. Это одно изменение состояния примерно каждые семь с половиной минут — в одном регионе, для одного типа ресурса.

Теперь наложим на это ежедневный цикл сканирования. Если ваш CSPM делает выборку раз в 24 часа, а 20% уязвимостей существуют менее двух минут, вы пропускаете их с вероятностью, которая округляется до единицы. Даже 30-минутный хвост, когда 99% удалённых снимков уже исчезло, находится хорошо внутри порога шума большинства расписаний управления состоянием безопасности. Производственные инциденты в финтехе, которые я наблюдал, обычно выглядят так: журнал аудита показывает, что неправильная конфигурация существовала, сканер не видит ничего, а постмортем спорит о том, упало ли дерево в лесу.

Aryon не ограничился подсчётом мерцаний. Они взяли выборку из 24 публично доступных снимков RDS, восстановили их и изучили содержимое. Восстановленные базы данных содержали идентификаторы AWS-аккаунтов, адреса электронной почты, потенциальные секреты, паттерны, характерные для закрытых ключей, и признаки финансовых данных. На этом извлечение было остановлено — это ответственный подход, — но сигнал недвусмысленный: эти эфемерные уязвимости не пустые тестовые заглушки. Они содержат именно то, что нужно злоумышленнику.

Мониторируемая поверхность вышла за пределы RDS. Aryon также наблюдал за снимками Amazon DocumentDB, Amazon Machine Images и документами AWS Systems Manager — всеми типами ресурсов, поддерживающими публичный доступ по замыслу. Это не уязвимость AWS. Это ошибка конфигурации со стороны клиента, и AWS годами предупреждает не хранить чувствительные данные в публично доступных ресурсах. Проблема в том, что современная платформенная команда вносит сотни изменений в инфраструктуру в день. Часть из них будет ошибочной. Вопрос в том, обнаружат ли ваши средства контроля это за секунды или за часы.

Что действительно нового

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

Второй действительно новый момент — экономика атаки. Злоумышленнику не нужно эксфильтрировать базу данных в течение окна. Достаточно выполнить копирование снимка в собственный AWS-аккаунт. Как только копия сделана, исходный владелец может отозвать публичный доступ сколько угодно — данные уже ушли. Это переосмысляет ShutterGap: из состояния гонки он превращается в примитив персистентности. Две минуты уязвимости равны постоянной компрометации — если кто-то следит.

И кто-то следит. Публичные инвентари AWS-ресурсов тривиально перечислимы. Любой компетентный злоумышленник может запустить непрерывный опросчик против тех же API, которые использовал Aryon, и скопировать всё интересное в момент появления. Стоимость такой инфраструктуры ничтожна по сравнению с ценностью одного производственного снимка RDS с учётными данными внутри.

Моё мнение: это смещает разговор о CSPM от «сколько находок мы закрыли на этой неделе» к «что мы предотвратили от возможности создания с самого начала». Рекомендации Aryon делают упор на Service Control Policies — и это правильный инстинкт. SCP скучны, не генерируют красивых дашбордов, и работают. Блокировка изменений атрибутов публичного доступа к снимкам, поддержание блокировки публичного доступа к AMI и запрет публичного доступа к документам SSM — всё это однократные записи политик, которые навсегда нейтрализуют целые классы находок. Сравните это с оплатой аналитика за триаж одного и того же повторяющегося алерта 40 раз в квартал.

Что уже учтено командами безопасности

Большинство опытных платформенных лидов уже подозревали, что ежедневные сканирования недостаточны. Это уже учтено. Каждый, кто работал с серьёзной облачной инфраструктурой, видел, как разработчик открывал бакет в публичный доступ в 14:00 и закрывал в 14:04, и понимал нутром, что ни один сканер никогда этого не увидит. Что не было учтено — масштаб. Шесть новых публичных снимков RDS за 90 минут в одном регионе — это не один разработчик, допустивший ошибку. Это системная модель поведения, вероятно связанная с рабочими процессами копирования снимков, скриптами межаккаунтного доступа и тестированием аварийного восстановления, которое кратковременно включает публичный доступ как сокращение.

Также уже учтено: идея о том, что предотвращение лучше обнаружения в облачной безопасности. Все говорят это на конференциях. Новое — конкретное измерение, которое точно показывает, насколько сильно проигрывает обнаружение, когда окно уязвимости меньше двух минут. Это число является рычагом обоснования бюджета. Если вы CTO и 90% расходов на облачную безопасность — это инструменты обнаружения, а 10% — превентивные ограничения, это исследование — то самое письмо, которое нужно отправить, чтобы изменить соотношение.

Что не учтено: аспект криминалистики CloudTrail. Анализ CloudTrail на события RDS ModifyDBSnapshotAttribute, EC2 ModifyImageAttribute и SSM ModifyDocumentPermission — это стандартная рекомендация, но большинство команд, с которыми я работал, смотрят на эти логи только после инцидента. Выполнение непрерывного запроса к ним с алертингом при изменении атрибута на публичный закрывает разрыв в видимости без ожидания следующего сканирования CSPM. Это по существу бесплатно, если вы уже отправляете CloudTrail в SIEM. Неудобная правда: большинство организаций этого не делают, или делают, но никогда не запрашивают.

Контраргументы

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

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

Есть также разумный аргумент, что выборка из 24 снимков мала. Aryon остановил извлечение ответственно — это правильно, — но это означает, что утверждение о «значимой деловой информации» опирается на узкую базу. Скептик мог бы возразить, что большинство мелькнувших снимков — пустые тестовые заглушки. Возможно. Но если даже однозначный процент содержит реальные секреты, ожидаемые потери в год на крупной инфраструктуре огромны. Базовая ставка не должна быть высокой, чтобы риск оправдывал исправление.

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

  • Ежедневные сканирования CSPM не видят ShutterGap. При 20% публичных снимков RDS, уязвимых менее двух минут, и 99%, исчезающих за 30 минут, 24-часовой цикл не обнаруживает почти ничего.
  • Предотвращение через SCP — настоящее решение. Заблокируйте ModifyDBSnapshotAttribute для публичного доступа, сохраните блокировку публичного доступа к AMI и предотвратите публичный доступ к документам SSM на уровне организации. Сделайте это один раз и спите спокойно.
  • Относитесь к уязвимости как к постоянной, а не временной. Злоумышленнику нужны секунды, чтобы скопировать снимок в свой аккаунт. Отзыв публичного доступа после факта не отменяет компрометацию.
  • Подключите CloudTrail к оповещению в реальном времени. Отслеживайте события RDS ModifyDBSnapshotAttribute, EC2 ModifyImageAttribute и SSM ModifyDocumentPermission по мере их возникновения, а не при следующем квартальном обзоре.
  • Требуйте шифрования для новых экземпляров RDS. Это не остановит уязвимость, но повысит стоимость восстановления скопированного снимка в чужом аккаунте и даст время для криминалистики.

Часто задаваемые вопросы

В: Что такое ShutterGap и почему это важно для пользователей AWS?

ShutterGap — термин, введённый Aryon Security для обозначения разрыва в видимости, возникающего, когда AWS-ресурсы становятся публично доступными на очень короткое время — часто минуты — и удаляются до того, как сканеры безопасности их замечают. Это важно, потому что 20% публичных снимков RDS, наблюдавшихся Aryon, были видны менее двух минут — значительно ниже разрешения ежедневных сканирований CSPM, а значит, большинство уязвимостей никогда не генерируют алерт.

В: ShutterGap — это уязвимость AWS?

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

В: Что командам безопасности следует сделать в первую очередь для снижения рисков ShutterGap?

Начните с Service Control Policies, блокирующих изменения атрибутов доступа к снимкам и запрещающих публичный доступ к AMI и документам SSM. Затем настройте алертинг CloudTrail для событий ModifyDBSnapshotAttribute, ModifyImageAttribute и ModifyDocumentPermission, чтобы любое переключение в публичный доступ вызывало реакцию в почти реальном времени, а не ожидало следующего сканирования.

AD
Alex Drover
RiverCore Analyst · Dublin, Ireland
ПОДЕЛИТЬСЯ
// ПОХОЖИЕ СТАТЬИ
ГлавнаяРешенияПроектыО насКонтакт
Новости06
Дублин, Ирландия · ЕСGMT+1
LinkedIn
🇷🇺RU