ShutterGap: Чому щоденні сканування CSPM пропускають 99% витоків AWS-снапшотів

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

Цифри

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

Тепер накладіть на це добовий розклад сканування. Якщо ваш CSPM перевіряє стан раз на 24 години, а 20% вразливостей існують менше двох хвилин, ви їх пропускаєте з імовірністю, що наближається до одиниці. Навіть 30-хвилинний хвіст, де вже зникло 99% видалених снапшотів, добре вписується в шумовий поріг більшості розкладів posture management. Виробничі інциденти, які я бачив у фінтех, зазвичай виглядають так: журнал аудиту підтверджує, що хибна конфігурація існувала, сканер нічого не показує, а на постмортемі сперечаються про те, чи впало дерево в лісі.

Aryon не зупинилися на підрахунку «мерехтінь». Вони взяли вибірку з 24 публічно доступних RDS-снапшотів, відновили їх і подивилися, що всередині. Відновлені бази даних містили ідентифікатори AWS-акаунтів, електронні адреси, потенційні секрети, патерни, схожі на приватні ключі, та ознаки фінансових даних. Дослідники зупинили вилучення на цьому етапі — це відповідальне рішення, — але сигнал однозначний: ці ефемерні вразливості не є порожніми тестовими об'єктами. Вони містять саме те, що потрібно зловмиснику.

Поверхня моніторингу виходила за межі RDS. Aryon також спостерігали за снапшотами Amazon DocumentDB, Amazon Machine Images та документами AWS Systems Manager — усі ці типи ресурсів підтримують публічне розповсюдження за задумом. Жодна з цих проблем не є вразливістю AWS. Це помилки конфігурації клієнтів, і AWS роками попереджала клієнтів не зберігати чутливі дані в публічно доступних ресурсах. Проблема в тому, що сучасна платформна команда щодня випускає сотні змін інфраструктури. Певна частка з них буде помилковою. Питання в тому, чи ловлять ваші засоби контролю їх за секунди або за години.

Що справді нового

Концепція хибно налаштованих публічних снапшотів не нова. Новим є емпіричний вимір тривалості вразливості та операційний висновок, що з цього випливає. Роками індустрія продавала posture management як відповідь на хмарні хибні конфігурації. Купи сканер, підключи до 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-інстанцій. Це не зупинить вразливість, але підвищить вартість відновлення скопійованого снапшота в чужому акаунті та дасть час для криміналістики.