Как обнаружить и обезопасить бесхозные ИТ-активы организации

Подробный гид по обнаружению забытых и устаревших серверов, API endpoints, учетных записей, веб-сайтов и других ИТ-активов (и по реагированию на них)

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

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

Физические и виртуальные серверы

Приоритет: высокий. Уязвимые серверы — это точки входа для кибератак, которые при этом потребляют ресурсы и создают риски для регуляторного соответствия.

Распространенность: высокая. Физические и виртуальные серверы остаются бесхозными в крупных инфраструктурах после проектов по миграции или после слияния и поглощения компаний. Часто оказываются забытыми тестовые серверы, которые уже не используются после запуска ИТ-проектов, а также веб-серверы для неактуальных проектов, работающие без домена. Масштаб последней проблемы иллюстрирует статистика сервиса Let’s Encrypt — половина запросов на продление домена в 2024 году приходила от устройств, которые более не связаны с запрошенным доменом. Число таких устройств — порядка миллиона.

Обнаружение: ИТ-служба должна внедрить процесс автоматической сверки конфигураций (Automated Discovery and Reconciliation, AD&R), который позволяет комбинировать результаты сетевого сканирования и облачной инвентаризации с данными в базе управления конфигурациями (CMDB). Это позволяет своевременно обнаруживать устаревшую и противоречивую информацию об ИТ-активах и находить сами забытые активы.

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

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

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

Забытые учетные записи пользователей, служб и устройств

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

Распространенность: очень высокая. Особенно часто забывают технические учетные записи, аккаунты подрядчиков, а также не именные учетные записи.

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

Реагирование: после сверки с бизнес-владельцем сервиса или руководителем сотрудника просто деактивировать или удалять устаревшие учетные записи. Масштабным решением проблемы станет комплексная система управления identity (IAM). В ней создание и удаление «учеток» и выдача им прав будут тесно переплетены с процессами HR.

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

Забытые хранилища данных

Приоритет: критический. Плохо контролируемые данные в доступных извне БД, облачных хранилищах и корзинах, корпоративных файлообменных сервисах (даже «безопасных») являются ключевым источником крупных утечек в 2024–2025 годах. Очень часто в этих утечках оказываются сканы документов, медицинские карты и личные данные, поэтому инциденты ИБ ведут также к штрафам за нарушение HIPAA, GDPR, ФЗ-152 и других регламентов обработки персональных и конфиденциальных данных.

Распространенность: высокая. Архивные данные, копии данных у подрядчиков, прошлые версии баз после миграции на новые системы — все это во многих организациях не учитывается и остается в доступе на годы и даже десятилетия.

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

• встроенные в решения крупных поставщиков подсистемы аудита (AWS Macie, Microsoft Purview);
• специализированные решения data discovery и data security posture management;
• автоматизированный анализ журналов инвентаризации наподобие S3 Inventory.

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

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

Неиспользуемые приложения и сервисы на серверах

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

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

Обнаружение: при регулярном аудите программных конфигураций. Для эффективного аудита у серверов должна быть своего рода «ролевая модель», а для каждой серверной роли — список ПО, нужного такому серверу. Кроме CMDB, в аудите пригодится широкий спектр инструментов — от OpenSCAP и Lynis, более сфокусированных на соответствии политикам и «здоровье» системы, до многоцелевого osquery, сканера уязвимостей OpenVAS и даже анализаторов сетевого трафика.

Реагирование: провести плановый разбор работы серверов с их бизнес-владельцами. Если приложение или сервис запущены на сервере без необходимости, их отключают. Для минимизации подобных ситуаций внедрите в организации принцип наименьших привилегий и применяйте укрепленные наборы ПО для типовых серверов (hardened base images / server templates), чтобы ничего лишнего не было запущено сразу, «из коробки».

Устаревшие API

Приоритет: высокий. Через API-доступ злоумышленники часто извлекают важные данные в больших объемах, а также осуществляют проникновение в организацию. В 2024 году число API-атак выросло на 41%, причем злоумышленники стараются найти именно устаревшие API, часто выдающие данные с меньшим числом проверок и ограничений, как случилось с утечкой на 200 млн записей X/Twitter.

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

Обнаружение: на уровне WAF или NGFW необходимо контролировать трафик конкретных API, чтобы обнаруживать аномалии (возможную эксплуатацию или эксфильтрацию), но также отмечать API, трафик к которым минимален.

Реагирование: по найденным малоактивным API необходимо совместно с бизнесом выработать план их отключения и перевода оставшихся пользователей на более новые версии.

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

ПО с устаревшими зависимостями и библиотеками

Приоритет: высокий. Именно здесь скрываются масштабные критические уязвимости наподобие Log4shell, ведущие к компрометации организаций и регуляторному несоответствию.

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

Обнаружение: совместное использование систем управления уязвимостями (VM/CTEM) и систем анализа состава ПО (Software Composition Analysis, SCA). Для внутренней разработки — обязательное использование сканеров и комплексных систем защиты, интегрированных с конвейером CI/CD и предотвращающих сборку ПО с устаревшими компонентами.

Реагирование: регламенты компании должны требовать от ИТ и разработки систематически обновлять зависимости ПО. При сборке собственного ПО анализ зависимостей должен быть частью проверки кода (code review), для внешнего ПО важно проверять статус и возраст зависимостей на регулярных аудитах.

Для внешних поставщиков ПО обновление зависимостей должно быть контрактным требованием, влияющим на срок поддержки и бюджет проекта. Чтобы эти требования были выполнимы, нужно поддерживать актуальный перечень компонентов программного обеспечения (Software Bill of Materials, SBOM).

Больше о том, как своевременно и эффективно устранять уязвимости — в отдельном материале.

Забытые веб-сайты

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

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

Обнаружение: на уровне ИТ необходимо вести реестр всех публичных сайтов и доменов и уточнять статус с владельцами сайта на ежемесячной или ежеквартальной основе. Дополнительно можно использовать сканеры или мониторинг DNS, отслеживая домены, связанные с ИТ-инфраструктурой компании. Еще один слой защиты обеспечивают сервисы Threat Intelligence, которые могут сами обнаруживать любые сайты, связанные с брендом.

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

Неиспользуемые сетевые устройства

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

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

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

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

11.12.2025