Какие внешние сервисы чаще становятся точкой входа в ИТ-инфраструктуру компаний

На внешнем периметре опасен не сам факт наличия VPN, SSH, OWA, сервиса обмена файлами или административного интерфейса веб-приложения. Такие сервисы часто нужны бизнесу для удаленной работы, сопровождения инфраструктуры, обмена файлами, поддержки клиентов и интеграций с партнерами. Риск возникает, когда к ним вовремя не применяют принятые в компании политики безопасности.

Поэтому для CISO важно оценивать каждый внешний сервис по двум вопросам: «что он дает атакующему?» и «зачем он нужен бизнесу на периметре?» Главное в проверке внешнего периметра — это не количество закрытых портов, а время между фактическим появлением нового сервиса и его обнаружением командой защиты. Об этом в статье для читателей Кибер Медиа расскажет Павел Загуменнов, руководитель BI.ZONE EASM.

Почему внешний сервис становится точкой входа

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

Даже если сегодня сервис настроен корректно, завтра ситуация может измениться. Например, свежая уязвимость способна повысить риск его компрометации. Так, CVE-2025-20352 позволяла злоумышленнику, обладающему community string, не просто прочитать конфигурацию сетевого устройства, а выполнить на нем произвольный код.

Из этого следует: недостаточно только отслеживать уязвимости — нужно контролировать само появление новых внешних точек доступа на периметре. Это позволит снижать поверхность атаки и не тратить время на срочный патчинг лишних систем.

Какие внешние сервисы становятся точками входа для атакующих

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

1. Открывающие вход во внутреннюю сеть.

2. Концентрирующие данные.

3. Позволяющие управлять инфраструктурой.

Сервисы, которые открывают вход во внутреннюю сеть

К этой группе относятся VPN, RDP, VNC, SSH и панели удаленного администрирования. Сами по себе они не опасны: бизнесу нужен удаленный доступ для сотрудников и подрядчиков, а администраторам — инструменты для сопровождения инфраструктуры. Риск возникает, когда такие сервисы оказываются доступны из интернета без строгого ограничения источников, MFA, контроля сессий, назначенного владельца и SLA на критичные обновления.

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

Показательный пример — CVE-2025-20333, уязвимость в VPN-веб-сервере решений Cisco Secure Firewall ASA и FTD. Она могла позволить удаленному аутентифицированному атакующему выполнить код на устройстве и поставить под угрозу все пользовательские сессии. Своевременный патчинг и MFA могли снизить риски компаний, тогда как наличие неучтенных сервисов VPN на периметре увеличивало вероятность успешной атаки.

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

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

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

Сервисы, где концентрируются данные

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

К этой категории активов относятся:

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

· Файлообменники. Seafile, MOVEit, FTP-/SFTP-серверы и похожие системы создавались для передачи важных документов, поэтому в них концентрируются договоры, персональные данные, финансовые отчеты, клиентские выгрузки и архивы.

· Базы данных, поисковые и кеширующие системы. MongoDB, Redis, Elasticsearch, PostgreSQL и MySQL редко должны быть доступны из интернета напрямую. На внешнем периметре они чаще появляются из-за тестовых стендов, временных правил межсетевых экранов или забытых dev-сред. Последствия компрометации обычно прямые — выгрузка данных. При этом утечка клиентской базы или пользовательских учетных сведений может привести к серьезному ущербу для бизнеса.

Для CISO главный вывод простой: такие сервисы нужно рассматривать как активы с высоким ущербом при компрометации. Если бизнесу не нужен внешний доступ к ним, сервисы нужно убрать с периметра. 

Сервисы, которые дают контроль над инфраструктурой

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

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

Похожий риск возникает в контуре разработки и эксплуатации, но уже на уровне цепочки поставки ПО. Открытые Kubernetes API, Docker API, административные панели Jenkins и GitLab могут дать доступ к цепочкам сборки, секретам, контейнерам и ключам доступа в облаке. В таком случае компрометация одного сервиса превращается из локального инцидента в риск выпуска вредоносного компонента от имени компании или захвата облачной инфраструктуры.

Практический вывод: сервисы управления инфраструктурой должны быть первыми кандидатами на вывод с публичного периметра.

Что делать CISO

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

Практический порядок действий:

1. Быстро ответить на вопрос: «Что доступно извне прямо сейчас?» При любой необходимости команда должна за часы, а не за дни, понять, какие сервисы присутствуют на внешнем периметре.

2. Убрать с периметра все сервисы без явного бизнес-обоснования. Для VPN, RDP, SSH, OWA, MFT, DevOps-панелей, баз данных и административных интерфейсов должны быть определены владелец, причина внешней доступности, ограничения доступа, требования к MFA, дата пересмотра и допустимый срок устранения риска.

3. Приоритизировать риски по последствиям, а не только по названию CVE. В первую очередь внимания требуют сервисы, которые дают доступ во внутреннюю сеть, к чувствительным данным или позволяют управлять инфраструктурой. Дополнительный приоритет получают уязвимости с доступным эксплоитом или подтвержденными случаями эксплуатации, выявленными через threat intelligence.

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

Как управлять внешней поверхностью атаки

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

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

На практике это выглядит так:

1. Появляется новая уязвимость в VPN, почтовом сервере, сетевом устройстве, DevOps-платформе или другом сервисе, который может быть доступен из интернета.

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

3. Глубокая инвентаризация веб-приложений помогает оценить потенциальное влияние уязвимости: определить используемые технологии — языки программирования, фреймворки, CMS, веб-серверы и другие компоненты, которые могут быть затронуты.

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

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

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