Признаки компрометации облачной инфраструктуры: как распознать угрозу внутри периметра 

Облачная инфраструктура существенно отличается от классической on-premise среды с точки зрения обнаружения угроз:

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

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

Безопасность информации в облаке должна быть реализована не только облачным ЦОД, но и выстроенной системой защиты на стороне самой организации.

Внезапный массовый отток данных ночью или в выходные — один из наиболее явных поведенческих сигналов.

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

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

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

50 неверных попыток ввода пароля за 5 минут — это не пользователь, забывший пароль. Это либо автоматизированный перебор, либо попытка использования частично известных учетных данных.

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

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

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

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

Что помогает: мониторинг в режиме реального времени с автоматическим уведомлением при прекращении поступления событий от конкретного источника; изоляция доступа к журналам безопасности — их не должен иметь возможности изменить или удалить обычный пользователь или администратор приложения; хранение журналов в отдельной системе с ограниченным доступом.

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

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

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

Иногда первый признак утечки — не техническое обнаружение, а появление данных компании в открытом доступе: на теневых форумах, в Telegram-каналах или на специализированных ресурсах. К моменту обнаружения утечка уже произошла и данные доступны неограниченному кругу лиц. Задача трансформируется из предотвращения в управление последствиями.

Что помогает: периодический мониторинг (не реже раза в полгода-год) открытых источников на предмет появления корпоративных данных — доменных имен, email-адресов сотрудников, фрагментов клиентских баз; использование специализированных сервисов мониторинга утечек; регулярное сканирование на уязвимости, которые могут быть использованы для проникновения.

При обнаружении данных в открытых источниках — немедленное уведомление Роскомнадзора в сроки, установленные Законом № 152-ФЗ: 24 часа для первичного уведомления, 72 часа для итогового.

1) Несет ли организация ответственность за безопасность данных в облаке?

Да. Облачный провайдер отвечает за безопасность инфраструктуры. Безопасность данных, приложений и учетных записей — ответственность организации-оператора.

2) Зачем нужна SIEM в облачной инфраструктуре?

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

3) Как быстро нужно реагировать при обнаружении признаков компрометации?

Немедленно. При подозрении на инцидент — немедленная изоляция подозрительной учетной записи или сегмента инфраструктуры, параллельно — начало расследования. Промедление увеличивает объем ущерба.

4) Что делать, если данные компании обнаружены в открытых источниках?

Зафиксировать факт, начать внутреннее расследование и немедленно уведомить Роскомнадзор: 24 часа — первичное уведомление, 72 часа — итоговое с результатами расследования (Закон № 152-ФЗ).

5) Помогает ли многофакторная аутентификация при атаках методом перебора паролей?

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