Антон Грецкий

Когда говорят о забытых ресурсах в облаке, обычно вспоминают старые виртуальные машины. Но сама виртуальная машина далеко не всегда представляет главную проблему. Гораздо интереснее то, что осталось вокруг нее.

Учетная запись или сервисный аккаунт никуда сами по себе не исчезают. Они могут продолжать существовать в AWS, Azure, Active Directory или другой системе. Старый SSH-ключ может оставаться доверенным на действующем сервере. API-токен, который когда-то создали для удаленного приложения, может по-прежнему давать доступ к базе данных или стороннему SaaS. При выводе сервиса из эксплуатации возникает проблема: сам сервис исчезает, а связанные с ним права — нет.

Один из наглядных сценариев связан с захватом поддомена. Представим, что компания запустила облачное приложение и привязала к нему корпоративный поддомен. Через некоторое время проект закрыли. Приложение удалили, однако CNAME-запись в DNS осталась, что для самой организации может выглядеть как остаток старой конфигурации. Для злоумышленника такая запись представляет интерес, потому что она продолжает указывать на место, где раньше находилось приложение.

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

Старые ключи, вебхуки и почта

DNS – только один из вариантов. После вывода сервиса из эксплуатации часто остаются учетные данные: сервисные аккаунты, токены, API-ключи, секреты, сертификаты и SSH-ключи.

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

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

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

Самые опасные «призраки» могут вообще ничего не делать

Отдельная категория забытых ресурсов – копии данных. Виртуальную машину давно удалили, но остались снапшоты, образы, резервные копии или выгрузки баз данных.

Активные системы регулярно обновляются, получают security-патчи и подключены к мониторингу. Старый образ виртуальной машины или бэкап трехлетней давности сохраняет конфигурацию и уязвимости того времени, когда его создали.

У забытых копий есть еще одна проблема — они часто находятся вне привычного контура наблюдения. Работающий сервер может быть подключен к SIEM, IDS, IPS и другим системам контроля. Снапшот или выгрузка базы на сетевом диске просто лежат без присмотра.

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

Есть и вполне приземленный экономический эффект. Снапшоты и бэкапы постепенно разрастаются, занимают место в облачном хранилище или на собственных СХД, и компания продолжает платить за информацию, которая давно потеряла практическую ценность.

Почему автоматизация не спасает от забытых ресурсов

Почему при наличии Terraform, Ansible и другой автоматизации инфраструктура все равно постепенно превращается в «дикий запад»? Одна из главных причин в разрыве между реальным состоянием облака и кодом, который это состояние должен описывать.

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

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

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

У самой автоматизации тоже есть архитектурные ограничения. Тот же Terraform – это не око Саурона. Он работает с ресурсами, которые описаны в его state file.

Есть и динамические ресурсы, так называемые side effects, которые появляются как побочный результат работы других систем. Например, при развертывании Kubernetes-кластера автоматически создаются балансировщики, диски, PVC и другие компоненты. Kubernetes их создает, а Terraform может не знать об их существовании. При удалении кластера такие ресурсы способны остаться в облаке.

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

Главная сложность – понять, что действительно можно удалить

Когда компания начинает искать забытые ресурсы, возникает другая проблема: неактивность еще не означает ненужность. Резервная система может почти не обрабатывать пользовательский трафик и при этом быть критически важной. Например, standby-база должна получать репликацию от основного узла. Если смотреть только на пользовательский трафик, такой ресурс легко принять за заброшенный.

Поэтому нужно обратить внимание и на связи с остальной инфраструктурой. У standby-узла можно проверить входящий трафик репликации. У резервного сервера – обращения систем мониторинга, health check, логи обновлений ОС, работу агентов безопасности и резервного копирования.

Имеет значение и период проверки. Некоторые ресурсы нужны раз в квартал или даже раз в год. Сервер для формирования годовой отчетности большую часть времени практически бездействует. Отсутствие активности за последние 30 дней в таком случае не говорит о его ненужности.

Дальше стоит посмотреть на окружение ресурса. DNS-записи, IP-адрес, присутствие в пулах балансировщиков, GeoDNS и failover-скриптах, правила Firewall и Security Groups дают гораздо более полную картину. Если к узлу разрешен доступ только с основного сервера приложений по специфическим портам репликации, это может быть признаком disaster recovery-компонента.

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

Один из полезных способов смотреть на ресурс – оценивать его как потенциального «сироту». Кто его владелец? Что произошло с исходной системой? Как давно существует объект? Используют ли его другие сервисы, тестовые среды или аналитические системы?

Атакующий может увидеть компанию лучше, чем она сама себя

У внешней поверхности атаки есть неприятная особенность: ее часто проще увидеть снаружи, чем контролировать изнутри.

В крупной компании инфраструктура распределена между разработчиками, безопасниками, ИТ, маркетингом и подрядчиками. Каждая команда создает ресурсы и меняет существующие. Внутренняя инвентаризация при этом не всегда успевает за изменениями.

Атакующий смотрит на компанию иначе. Для него это единая цель.

Поддомены и IP-адреса видны в публичных источниках, DNS и логах сертификатов. Автоматизированное сканирование позволяет постоянно искать новые активы, поэтому забытый тестовый сервер может оставаться неизвестным внутренней команде и просматриваться из интернета.

Сопоставить внутреннюю картину с внешней позволяют OSINT и EASM – External Attack Surface Management. Например, история выданных сертификатов позволяет обнаружить поддомены, о которых уже забыли ответственные команды. Полученный список стоит сопоставить с внутренней документацией. Если внешний домен отсутствует во внутренней базе, это как минимум указывает на пробел в инвентаризации.

С точки зрения атакующего интерес представляют публичные хранилища, забытые базы данных и снапшоты, compute-инстансы с публичными IP-адресами, старые поддомены и ресурсы с признаками заброшенности. Такими признаками могут быть имена вроде «-test», «-dev», «-old», минимальный трафик, отсутствие обращений к API или базе данных.

Дополнительные вопросы возникают к старым версиям операционных систем и TLS, просроченным сертификатами, сохраненным в конфигурациях секретам, API-ключам, паролям и избыточным правам.

Что происходит после удаления сервиса

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

Сначала проверяется сетевой контур и DNS. Связанные с сервисом DNS-записи должны быть удалены, а домен после этого не должен резолвиться в IP-адрес удаленной инфраструктуры.

Отдельно нужно убедиться, что не осталось CNAME-записи на сторонний облачный сервис. Если ресурс там уже удален, такая запись может создать возможность для захвата поддомена.

Затем проверяются сертификаты и доступы. Если для сервиса выпускался отдельный SSL/TLS-сертификат, его необходимо отозвать через удостоверяющий центр, а статус можно проверить с помощью OpenSSL s_client или SSL Labs.

То же касается SSH-ключей и API-токенов. Нужно посмотреть конфигурационные файлы, authorized_keys на серверах и системы управления доступами. Ключи, созданные специально для конкретного сервиса, после его удаления тоже должны исчезнуть.

Следующий слой – интеграции. Внешние системы не должны продолжать отправлять данные на старый endpoint. Поэтому после удаления нужно проверить вебхуки в сторонних панелях, CRM, Telegram-ботах, GitHub, Stripe и других системах.

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

Отдельно нужно проверить резервные копии и политики их хранения. Автоматическое создание бэкапов для удаленного сервиса должно быть отключено. Старые архивы, если их хранение больше не требуется, удаляются в соответствии с внутренним регламентом. Если данные необходимо сохранить, их можно перевести в долгосрочное изолированное архивное хранение.

Поверхность атаки – это история всей инфраструктуры

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

Здесь могут использоваться EASM-решения – инструменты класса External Attack Surface Management, которые непрерывно мониторят интернет и уведомляют о появлении новых активов компании.

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

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

***

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

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