Кража без взлома: почему облака текут, а серверы остаются открытыми

Дорогая блокировка и дешевая кража

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

Директор по информационной безопасности ActiveCloud Антон Грецкий
Фото: ActiveCloud 

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

Свою роль играет и сама природа облачных технологий. S3-бакеты и другие хранилища часто остаются открытыми или имеют неверные настройки доступа. Злоумышленникам достаточно простого сетевого сканера, чтобы прощупать периметр, например, Nessus или RedCheck, и они находят такие уязвимости без усилий.

Двойное вымогательство: когда бэкапы не спасают

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

Из международной практики можно вспомнить инцидент, произошедший пару лет назад с правительством Объединенных Арабских Эмиратов. Этот кейс – типичный пример двойного вымогательства, переходной формы от простого шифрования к чистой краже. Хакеры охотились за данными о торговле нефтью. Группировка Oil Rig украла сведения, которые указывали на не вполне этичные действия власти в отношении собственных компаний и других государств. Злоумышленники потребовали выкуп и, по имеющейся информации, получили его.

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

Как в 2026 году ключи утекают к хакерам

Скомпрометированные учетные данные остаются главным вектором атак, но фокус сместился: взламывают не системы, а процессы. Фишинг никуда не исчез, наоборот, он стал более таргетированным и автоматизированным. Однако основные каналы утечек другие.

Главный риск – секреты в коде, или хардкод (жесткое зашивание) ключей, а также уязвимости CI/CD. Разработчики по-прежнему забывают токены в коде, но теперь хакеры запускают сканеры по публичным репозиториям вроде GitHub и взломанным приватным хранилищам. Между коммитом забытого секрета и его кражей проходят доли секунды. Отдельная проблема – shadow CI/CD (неофициальные, не контролируемые безопасностью конвейеры развертывания), когда утечки происходят через тестовые окружения, где переменные среды не отзываются после завершения скрипта, и через них злоумышленники получают доступ.

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

Третий вектор – identity-атаки (атаки на основе идентификационных данных). Ломать инфраструктуру сложно и заметно. Гораздо проще «работать» из-под легитимной учетной записи. Поэтому атакующие крадут учетные данные или подкупают сотрудников. Получив аккаунт администратора облака, злоумышленник получает прямой доступ к данным, а системы защиты не срабатывают: действия выглядят легитимными, как свои среди своих.

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

Где прячутся открытые S3-бакеты (даже когда «все починили»)

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

Самый массовый – теневые ИТ- и R&D-проекты (часто созданные сотрудниками в обход корпоративной ИТ-службы). Разработчики настраивают временные бакеты для быстрого обмена дампами баз данных или логами между командами в обход корпоративных политик безопасности, а после завершения задачи примерно в 90 % случаев про хранилища забывают. И они годами хранятся под названиями backup_test, test_data, transfer или backup_temp. Именно оттуда данные утекают чаще всего.

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

Проблема может быть связана и с настройками граничных сервисов (CloudFront, CDN). Сам бакет может быть закрыт, но перед ним стоит CDN для раздачи статики. Если политика доступа CDN неверная, злоумышленник получает содержимое бакета через URL кэширующего сервиса. В таком случае ограничения хранилища не работают.

Есть и специфика S3-совместимых хранилищ. AWS ужесточил настройки по умолчанию. Но появились DigitalOcean Spaces, Wasabi, Linode и локальные аналоги. У них настройки по умолчанию мягче для удобства пользователей. При этом компании ошибочно думают, что правила безопасности везде одинаковы.

Злоумышленники используют и сценарий захвата поддоменов. Если компания удалила бакет, но забыла удалить CNAME-запись DNS (тип DNS-записи, работающий как «псевдоним», указывающий один поддомен), то хакер создает бакет с тем же именем и перехватывает трафик поддомена для фишинга или сбора данных.

Как защититься, не замедляя разработку

Контроль привилегированного доступа не должен тормозить работу. Защита нужна не в виде глухой стены, а как умный турникет: пропускает того, кому действительно необходимо, и лишь на ограниченное время. Этого помогают добиться проверенные подходы. Во-первых, это JIT-доступ (Just-in-Time, «точно в срок»), который предполагает отказ от постоянных прав – инженер получает привилегии к облаку на время конкретной задачи, например, на два часа или до коммита. По истечении срока права отзываются автоматически.

Второй подход касается управления ключами (секрет-менеджмент). Их запрещено хранить в коде или переменных окружения. Вместо этого используются централизованные хранилища – HashiCorp Vault или AWS Secrets Manager. Они генерируют временные сессионные пароли под каждую задачу.

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

Что касается S3-бакетов и их аналогов, здесь важны автоматические политики: запрет публичного доступа на уровне организации, регулярные аудиты с помощью инструментов AWS Trusted Advisor или Scout Suite, а также автоматическое удаление «теневых» хранилищ по тегам и дате создания.

Заключение. Что на самом деле защищает облако

Экономика киберпреступности сместилась в сторону кражи данных, а не блокировки систем. Облачные технологии упростили доступ и для законных пользователей, и для хакеров. Слабые места известны: открытые бакеты, забытые ключи в коде, бесхозные аккаунты. Даже настроенный S3-бакет утекает через ошибки в Terraform, неверные политики CDN или теневые R&D-проекты.

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

Автор: Антон Грецкий, директор по информационной безопасности ActiveCloud