Внешняя поверхность атаки: забытые поддомены, старые панели, тестовые стенды и shadow IT

Невидимый периметр: как компании теряют контроль над тем, что сами же выставили в интернет

Введение: то, что вы не видите — видят атакующие

Представьте: три года назад маркетинговая команда запустила промо-сайт на поддомене promo2022.company.ru. Кампания завершилась, сайт забыли, но DNS-запись осталась. Сегодня этот поддомен указывает на удалённый ресурс Heroku — и любой желающий может зарегистрировать там аккаунт и разместить под вашим именем фишинговую страницу.

Это не гипотетический сценарий. Именно так устроена значительная часть реальных атак 2024–2025 годов.

Цифровая инфраструктура современной компании давно перестала быть чем-то статичным и хорошо очерченным. Она растёт органично: новые облачные сервисы, интеграции с партнёрами, тестовые окружения разработчиков, маркетинговые поддомены, SaaS-инструменты, которые отдел продаж подключил без ведома ИТ. Каждый из этих элементов — потенциальная точка входа для злоумышленника.

Статья будет полезна руководителям ИБ (CISO), ИТ-директорам, командам по безопасности, а также всем, кто занимается комплаенсом и управлением рисками. Мы разберём конкретные категории угроз, реальные инциденты, технические механизмы атак и практические меры контроля — с учётом российского регуляторного контекста 2025–2026 годов.

Что такое внешняя поверхность атаки — и почему она больше, чем вы думаете

Внешняя поверхность атаки (External Attack Surface) — это совокупность всех цифровых активов организации, доступных из интернета: домены и поддомены, IP-адреса, веб-приложения, API, облачные хранилища, VPN-шлюзы, сертификаты, административные панели и многое другое.

Управление внешней поверхностью атаки (External Attack Surface Management, EASM) — это непрерывный процесс обнаружения, инвентаризации и мониторинга всех таких активов с точки зрения атакующего [7]. Ключевое слово здесь — «непрерывный». Поверхность атаки меняется каждый день: новый сервис поднят в облаке, разработчик зарегистрировал поддомен для стенда, маркетинг подключил сторонний инструмент аналитики.

Традиционные сканеры уязвимостей работают от обратного: вы даёте им список известных активов, они проверяют эти активы. EASM переворачивает подход — он начинает с вашего доменного имени и двигается наружу, находя всё, что связано с организацией так, как это видит атакующий [2].

Согласно исследованию BI.ZONE CPT среди более чем 200 российских организаций, только 2% компаний действительно знают обо всех своих ИТ-активах. В остальных случаях в инфраструктуре обнаруживаются домены, сервисы, IP-адреса, устройства и программные компоненты, о которых службы ИТ и кибербезопасности либо не знают вовсе, либо не контролируют должным образом [1].

Почему разрыв так велик? Есть несколько системных причин:

1. Данные об активах хранятся в разных системах — CMDB, DNS, таблицах Excel, документации команд — и эти источники часто расходятся между собой [8]
2. Сотрудники, которым поручают составить список IP-пулов и доменов, нередко не понимают, зачем он нужен, и делают собственные допущения [8]
3. Скорость появления новых активов (облака, SaaS, CI/CD, интеграции) опережает возможности ручного учёта [9]
4. При смене команд или реструктуризациях «историческая память» об активах теряется

Четыре главных категории риска

Забытые поддомены и захват DNS

Поддомен — это не просто строка в DNS-таблице. Это доверие пользователей к вашему бренду. Когда кто-то видит support.company.ru, он предполагает, что это легитимный сервис компании. Именно это доверие и эксплуатируют атакующие.

Атака через захват поддомена (subdomain takeover) происходит следующим образом: компания создаёт поддомен, указывающий на внешний сервис — GitHub Pages, Heroku, AWS S3, Azure, Zendesk. Затем сервис деактивируется или удаляется, но DNS-запись остаётся. Атакующий обнаруживает «висящую» запись, регистрируется на том же внешнем сервисе и берёт поддомен под свой контроль [10].

Последствия захвата поддомена выходят далеко за рамки простого дефейса:

1. Фишинговые страницы под доверенным именем домена компании
2. Перехват файлов cookie сессии основного домена
3. Обход SPF, DKIM и DMARC — рассылка вредоносных писем якобы от вашей компании
4. XSS-атаки через доверенный контекст
5. SEO-манипуляции для дискредитации бренда [11]

Масштаб проблемы впечатляет. Исследователи Keytos сообщают об обнаружении более 15 000 уязвимых поддоменов в Azure ежемесячно, при этом лишь 2% организаций активно занимаются этой проблемой [12]. Сами разработчики Microsoft в какой-то момент имели более 700 поддоменов, уязвимых для захвата [12]. На HackerOne число ежегодно раскрываемых захватов поддоменов стабильно растёт с 2014 года [13].

Особенно тревожна эволюция этой техники. Исследование SentinelOne (октябрь 2024 — январь 2025 года) зафиксировало, как атакующие перехватывали удалённые S3-бакеты, которые использовались в CI/CD-пайплайнах правительственных структур, компаний из Fortune 500 и крупных open-source проектов. За четыре месяца исследователи, контролировавшие около 150 таких бакетов, получили свыше 8 миллионов запросов — включая запросы на обновление ПО, образы контейнеров и конфигурации SSLVPN [3]. Это уже не дефейс, а атака на цепочку поставок.

Отдельную угрозу представляет кампания SubdoMailing, раскрытая Guardio Labs: атакующие захватили более 8 000 легитимных доменов и 13 000 поддоменов от известных брендов для рассылки 5 миллионов вредоносных писем в день [14].

Открытые административные панели и устаревшие VPN

Вторая категория — административные интерфейсы, открытые в интернет без надлежащей защиты. Это могут быть панели управления маршрутизаторами и коммутаторами, веб-интерфейсы систем мониторинга, интерфейсы баз данных (phpMyAdmin, Adminer), административные консоли CMS, панели управления CI/CD (Jenkins, GitLab), интерфейсы Kubernetes и облачных сред.

Согласно данным отечественного провайдера EASM-сервисов, в открытых источниках обнаруживается более 32 тысяч баз данных Elasticsearch и MongoDB, открытых для всех, и более 88 тысяч хостов, использующих SMBv1 [15]. Это не абстрактные числа — каждый из этих хостов представляет собой конкретный риск для конкретной организации.

Отчёт Verizon Data Breach Investigations Report 2025, основанный на анализе более 22 000 инцидентов, фиксирует: кража учётных данных остаётся доминирующим вектором первоначального доступа (22% всех взломов), а 88% атак на базовые веб-приложения включали использование скомпрометированных учётных данных [16]. Эксплуатация уязвимостей при этом выросла на 34% год к году и заняла второе место (20%) — во многом за счёт атак на периметровые устройства и VPN [16].

Проблема административных панелей усугубляется тем, что по умолчанию многие системы используют стандартные учётные данные, которые никто не меняет. Verizon прямо указывает в DBIR 2024: «Злоумышленники продолжают использовать активы с учётными данными по умолчанию, простыми и легко угадываемыми паролями — через брут-форс, покупку или повторное использование данных из предыдущих утечек» [17].

Устаревшие VPN-шлюзы с известными CVE-уязвимостями составляют отдельную группу риска. Атакующие активно сканируют интернет в поисках устаревших версий Cisco ASA, Fortinet, Pulse Secure, Palo Alto Networks. Именно эти устройства стали основным вектором атак на критическую инфраструктуру в 2024–2025 годах. В DBIR 2025 особо отмечается рост эксплуатации zero-day в периметровых устройствах — они составили 22% от всех зафиксированных атак через уязвимости [16].

Тестовые стенды и среды разработки

Третья категория — пожалуй, наиболее недооцениваемая. Это dev-, staging- и pre-prod-окружения, которые разработчики поднимают для тестирования, а потом либо забывают отключить, либо оставляют открытыми намеренно — для удобства работы.

Испанское регуляторное ведомство AEPD в своём официальном руководстве прямо указывает: «По-прежнему распространены среды разработки и pre-production, в которых технические и организационные меры ослаблены, или которые открыты в интернет без мер безопасности, или заброшены, и их меры безопасности быстро устаревают» [18]. При этом нередко именно в тестовых средах используются реальные персональные данные для отладки — это создаёт дополнительные правовые риски.

Типичные проблемы тестовых стендов:

1. Слабые или дефолтные учётные данные (используются для удобства разработки)
2. Использование реальных производственных данных для воспроизведения ошибок
3. Отсутствие сегментации от производственной среды
4. Открытые порты отладки, не закрытые после тестирования
5. Секреты и API-ключи, зашитые в код (hardcoded)
6. Отсутствие регулярного обновления и патчинга

Классический пример: в ноябре 2023 года атакующие получили несанкционированный доступ к staging-среде New Relic, выполнили поисковые запросы и выгрузили данные, затронув часть клиентов [19].

Ещё более громкий прецедент: в январе 2024 года российская группировка Midnight Blizzard проникла в инфраструктуру Microsoft через тестовый аккаунт, не имевший многофакторной аутентификации. Атакующие применяли «распыление паролей» (password spraying) с низкой интенсивностью, чтобы избежать блокировки. Этот тестовый аккаунт имел повышенные привилегии, что позволило злоумышленникам получить доступ к переписке руководства компании и подразделений кибербезопасности [4]. Вывод Комитета по надзору за кибербезопасностью (CSRB): инцидент был предотвратим; причина — «неадекватная культура безопасности» Microsoft.

Согласно исследованию UpGuard, в ходе аналитики безопасности часто обнаруживаются открытые учётные данные к тестовым средам, которые могут стать точкой входа в производственную инфраструктуру — через «ступеньки» (stepping stones): сначала доступ к тестовому стенду, затем эскалация привилегий к продакшену [20].

В тестовых средах часто хранятся и секреты: API-ключи, токены сервисных аккаунтов, ключи доступа к облачной инфраструктуре. По данным GitHub, только за первые два месяца 2024 года в публичных репозиториях было обнаружено более миллиона подобных секретов [19].

Shadow IT: неучтённые активы под корпоративным именем

Shadow IT (теневые ИТ) — технологии, инструменты, сервисы и инфраструктура, используемые сотрудниками или подразделениями без ведома и одобрения ИТ- и ИБ-служб. В эпоху облаков и SaaS это явление приобрело новый масштаб.

Механизм прост: разработчик поднял облачный инстанс для быстрого теста; маркетинговое агентство зарегистрировало поддомен для рекламной кампании; сейлз-команда подключила сторонний CRM без согласования; финансовый отдел залил данные в Google Sheets и расшарил ссылку подрядчику. Каждое из этих действий расширяет поверхность атаки за пределы видимости ИБ-службы [9].

Согласно отчёту Brandefense 2025, именно shadow IT категорически увеличивает внешнюю поверхность атаки: любой неотслеженный SaaS-аккаунт, незаявленный поддомен, неуправляемый API — это потенциальная точка входа [21]. EASM-платформы используют комплексное сканирование интернета, перечисление DNS и облачно-нативные интеграции для непрерывного обнаружения и отслеживания таких «теневых» сервисов.

Российское исследование BI.ZONE CPT (январь 2026 года), охватившее более 200 российских организаций, фиксирует: теневые ИТ-активы — это не редкость, а норма. Они обнаруживаются у 98% проверенных компаний, и именно на них сосредоточены 78% всех выявленных уязвимостей [1]. После получения доступа через теневой актив злоумышленники могут «затаиться» на 42 дня в среднем, а в отдельных случаях — до 181 дня [1].

Существует дихотомия восприятия shadow IT среди ИТ-специалистов: 77% признают их потенциальные преимущества (повышение производительности), одновременно осознавая серьёзные риски для безопасности [22]. Это противоречие — один из главных барьеров на пути к эффективному управлению: запрет shadow IT без предоставления удобных корпоративных альтернатив лишь загоняет проблему глубже.

Российский контекст: атаки, регуляторика и рост ставок

Угрозы в цифрах

Россия входит в число наиболее приоритетных целей киберпреступников. По данным Positive Technologies, с июля 2024 по сентябрь 2025 года на Россию пришлось от 14% до 16% всех успешных кибератак в мире и 72% атак, зафиксированных в СНГ. Прогноз на 2025 год — рост числа успешных атак на 20–45% по сравнению с предыдущим годом; на 2026-й — ещё на 30–35% [23].

Доля успешных атак с утечкой информации выросла с 44% до 56% в 2024 году [23]. По данным ГК «Солар», суммарный объём утёкших у российских организаций данных за январь–сентябрь 2025 года составил около 748 ТБ — это в 138 раз больше, чем за аналогичный период 2024 года [24]. Ущерб от одной утечки данных, по оценкам самих компаний, может составлять до 140 млн рублей — и это ещё до введения оборотных штрафов [24].

По данным BI.ZONE, 13% атак на организации в России и других странах СНГ начинаются с эксплуатации уязвимостей в общедоступных приложениях — то есть именно с внешней поверхности атаки [25].

Регуляторные изменения 2025 года

С 30 мая 2025 года в России вступил в силу Федеральный закон № 420-ФЗ, кардинально ужесточивший ответственность за утечки персональных данных [5].

Новая шкала штрафов для организаций по масштабу утечки:

1. За утечку данных 1 000–10 000 физлиц — от 3 до 5 млн рублей
2. За утечку данных 10 000–100 000 физлиц — от 5 до 10 млн рублей
3. За утечку данных более 100 000 физлиц — от 10 до 15 млн рублей
4. За утечку биометрических данных — от 15 до 20 млн рублей
5. За повторную утечку — от 1% до 3% годовой выручки, но не менее 20 млн и не более 500 млн рублей [5]

Дополнительно с декабря 2024 года начала действовать статья 272.1 УК РФ, вводящая уголовную ответственность за незаконную передачу компьютерной информации с персональными данными — вплоть до 10 лет лишения свободы для организованных групп [26].

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

Как атакующий находит ваши слабые места

Разведка (reconnaissance) — первый этап любой целевой атаки. Современные инструменты позволяют выполнить пассивную разведку внешней поверхности организации за считанные часы, не взаимодействуя с целевыми системами напрямую.

Арсенал атакующего для обнаружения внешних активов:

1. Перечисление поддоменов — инструменты Subfinder, Amass, Assetfinder анализируют DNS, certificate transparency logs, сканы Shodan/Censys
2. Поиск «висящих» DNS-записей — проверка CNAME-записей, ведущих на несуществующие внешние ресурсы
3. Сканирование портов и сервисов — nmap, masscan в комбинации с сервисами типа Shodan и FOFA
4. Поиск открытых секретов — GitLeaks, TruffleHog сканируют публичные репозитории
5. Поиск через Google Dorks — операторы site:, intitle:, inurl: позволяют найти открытые панели управления и документы
6. Certificate Transparency — логи выданных SSL-сертификатов раскрывают поддомены, о которых организация могла забыть

Этот же арсенал доступен защитникам — именно так работают EASM-платформы: они воспроизводят взгляд атакующего, но систематически и непрерывно.

Чек-лист: практические шаги по управлению внешней поверхностью атаки

Инвентаризация — основа всего

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

1. Запросить адресные и доменные пулы у ИТ-департамента
2. Выгрузить все DNS-записи, включая исторические, из регистраторов и DNS-провайдеров
3. Проанализировать Certificate Transparency logs (crt.sh, censys.io) на предмет поддоменов
4. Провести OSINT с помощью Shodan, Censys, FOFA для обнаружения IP-адресов компании
5. Объединить данные из всех источников в единый реестр [8]
6. Установить регулярное автоматическое обновление — изменения происходят ежедневно

Поддомены: что проверять

1. Найти все CNAME-записи, ведущие на сторонние сервисы (AWS, Azure, Heroku, GitHub Pages, Netlify, Vercel и др.)
2. Для каждой такой записи проверить, существует ли соответствующий ресурс на стороне провайдера
3. Записи, ведущие на несуществующие ресурсы — «кандидаты на захват» — немедленно удалить
4. Добавить «очистку DNS» в чек-листы деактивации любого сервиса
5. Использовать Domain Verification ID у облачных провайдеров (функция Azure asuid.{subdomain}, Route 53 domain verification)
6. Проводить регулярный аудит — минимум ежеквартально [10]

Административные панели и периметровые устройства

1. Провести полное сканирование внешнего периметра на открытые административные порты (22, 23, 80, 443, 3389, 8080, 8443, 9200, 27017 и др.)
2. Для каждого открытого сервиса проверить версию ПО и наличие известных CVE
3. Административные интерфейсы, которые не должны быть публичными, — закрыть, ограничить IP-белым списком или перенести за VPN
4. Провести проверку на дефолтные учётные данные
5. Убедиться, что MFA включена для всех административных доступов
6. Составить план немедленного обновления VPN-шлюзов и периметровых устройств [16]

Тестовые и dev-среды

1. Провести инвентаризацию всех dev/staging/pre-prod окружений — включая облачные инстансы, поднятые разработчиками
2. Убедиться, что ни одно из них не доступно из публичного интернета без необходимости
3. Внедрить обязательное использование разных учётных данных для prod и non-prod сред
4. Запретить использование реальных персональных данных в тестовых средах; использовать обезличенные или синтетические данные
5. Добавить сканирование секретов (secrets scanning) в CI/CD-пайплайн
6. Настроить автоматическое отключение неиспользуемых стендов по таймеру
7. Применять одинаковые политики безопасности ко всем средам, включая тестовые [18]

Shadow IT

1. Использовать Cloud Access Security Broker (CASB) или аналогичные инструменты для обнаружения несанкционированного SaaS
2. Регулярно анализировать DNS-запросы и трафик для выявления обращений к неизвестным внешним сервисам
3. Создать «белый список» разрешённых облачных сервисов с прозрачным и быстрым процессом одобрения новых
4. Упростить процедуру согласования новых инструментов — сложные процессы стимулируют обход правил
5. Проводить обучение сотрудников о рисках shadow IT
6. Интегрировать EASM с управлением активами (CMDB) для поддержания актуального реестра

Типичные ошибки и как их избежать

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

Ошибка вторая — «война с тенью» вместо её освещения. Запретить всё несанкционированное ПО — не значит ликвидировать проблему: сотрудники начинают использовать личные устройства и личные аккаунты в рабочих целях, только теперь это ещё менее заметно. Решение: создавать удобные, быстро одобряемые корпоративные альтернативы.

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

Ошибка четвёртая — забытые DNS-записи при выводе сервисов из эксплуатации. Очевидная, но регулярно повторяющаяся ошибка. Чек-лист деактивации любого сервиса должен включать удаление DNS-записей как обязательный первый или последний шаг — до или сразу после удаления ресурса. Именно порядок действий критичен для предотвращения захвата поддомена [10].

Ошибка пятая — игнорирование периметровых активов подрядчиков. 30% всех взломов в DBIR 2025 связаны с третьими сторонами — вдвое больше, чем в 2024 году [27]. Внешняя поверхность атаки включает не только ваши прямые активы, но и все подключения к инфраструктуре партнёров и поставщиков.

Ошибка шестая — разрыв между ИТ и ИБ в части ответственности за активы. Когда непонятно, чья это зона ответственности, не следит никто. Реестр активов должен включать явного владельца для каждого элемента периметра.

Реальные кейсы: когда забытый актив стоил дорого

Кейс 1: атака на СДЭК через открытый периметр. 26 мая 2024 года группировка Head Mare атаковала компанию СДЭК — крупнейший логистический оператор России. Полное восстановление работоспособности заняло около 6 дней. По оценкам, основанным на данных о выручке компании, потери за этот период составили более 750 млн рублей без учёта репутационного ущерба и затрат на восстановление [28].

Кейс 2: NPM subdomain takeover и атака на цепочку поставок (2023). Атакующие обнаружили, что DNS-запись для assets.npmjs.com ведёт на удалённый S3-бакет. Перехватив этот бакет, они разместили там вредоносные бинарные файлы вместо легитимных пре-собранных пакетов для node-pre-gyp. Все пользователи, устанавливавшие затронутые npm-пакеты, загружали вредоносное ПО, способное похищать данные [12].

Кейс 3: Microsoft и Midnight Blizzard (январь 2024). Атакующие проникли в корпоративную сеть Microsoft через тестовый аккаунт без MFA с помощью атаки password spraying. Аккаунт имел избыточные привилегии. В результате была похищена переписка руководства компании и сотрудников подразделений кибербезопасности. CSRB признал инцидент предотвратимым [4].

Кейс 4: AT&T и незащищённый S3-бакет (2024). Компания AT&T допустила двухлетнее (с марта 2022 по март 2024 года) открытое хранение данных клиентов в незащищённом Amazon S3-бакете без контроля доступа. За период экспозиции данные были получены по меньшей мере 7 различными субъектами, а сам инцидент произошёл из-за того, что среда разработки была ненамеренно переведена в продакшен без прохождения процедуры проверки безопасности [29].

Тренды: как меняется угрозный ландшафт в 2025–2026 годах

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

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

Тренд третий — рост атак через цепочку поставок. Треть всех взломов в DBIR 2025 связана с третьими сторонами [27]. Внешняя поверхность атаки теперь включает активы всех ваших поставщиков, интеграторов и партнёров — особенно тех, кто имеет доступ к вашей инфраструктуре.

Тренд четвёртый — конвергенция EASM с управлением данными. Регуляторный давление в России нарастает: оборотные штрафы за утечки персональных данных требуют не только технической защиты периметра, но и понимания того, где именно персональные данные хранятся и обрабатываются — включая теневые и неучтённые системы [5].

Тренд пятый — непрерывный мониторинг вместо периодических аудитов. Gartner прогнозировал к 2025 году переход 60% организаций на конвергированные EASM+DRP-решения [6]. BI.ZONE и другие российские вендоры активно развивают EASM-сервисы именно в этом направлении: сервис BI.ZONE CPT обеспечивает непрерывную оценку защищённости и отслеживание новых сервисов на периметре [25].

«Пятый фактор»: контроль данных там, где атакующие их ищут

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

Именно эту задачу решает платформа «Пятый фактор» — on-prem решение для автоматического обнаружения, инвентаризации и контроля персональных данных в корпоративных системах: БД, хранилищах, почте, AD/LDAP, CRM, 1С, API.

Ключевое отличие платформы — принцип privacy-by-design: система работает исключительно с метаданными, структурой и агрегатами, не передавая и не храня «сырые» персональные данные. Это означает, что сама платформа не становится дополнительным источником риска — критически важное свойство в контексте расширяющейся поверхности атаки.

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

В условиях оборотных штрафов по ФЗ-420, вступивших в силу в мае 2025 года, непрерывный контроль над тем, где и какие персональные данные обрабатываются в организации, — не опция, а необходимость.

Заключение: что делать прямо сейчас

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

Практический план на ближайшие 30 дней:

1. Провести пассивную разведку собственного периметра: crt.sh для поиска поддоменов, Shodan для поиска открытых сервисов, проверку DNS-зон на «висящие» записи
2. Найти и закрыть все тестовые среды, доступные из публичного интернета без явной необходимости
3. Провести аудит МФА на всех административных интерфейсах
4. Добавить «удаление DNS-записи» в чек-листы вывода любого сервиса из эксплуатации
5. Запустить процесс инвентаризации облачных активов и SaaS-подписок

На горизонте 3–6 месяцев — внедрить автоматизированный непрерывный мониторинг внешней поверхности (EASM-инструмент или сервис) и интегрировать его с процессами управления уязвимостями и инцидентами.

Нельзя защитить то, чего не видишь. Начните видеть.

Источники

[1] BI.ZONE: 98% российских компаний имеют теневые ИТ-ресурсы — https://www.anti-malware.ru/news/2026-01-29-111332/48867

[2] Breachsense: External Attack Surface Management (ESG data) — https://www.breachsense.com/external-attack-surface-management/

[3] SentinelOne: Re-Assessing Risk — Subdomain Takeovers As Supply Chain Attacks — https://www.sentinelone.com/blog/re-assessing-risk-subdomain-takeovers-as-supply-chain-attacks/

[4] Cloud Security Alliance: Reflecting on the 2024 Microsoft Breach — https://cloudsecurityalliance.org/blog/2025/09/15/reflecting-on-the-2024-microsoft-breach

[5] КонсультантПлюс: Персональные данные — новые штрафы с 30 мая 2025 года — https://www.consultant.ru/legalnews/28492/

[6] Help Net Security: ZeroFox launches EASM (Gartner prediction) — https://www.helpnetsecurity.com/2024/03/12/zerofox-external-attack-surface-management-easm/

[7] Trend Micro (RU): Что такое управление внешней поверхностью атаки (EASM)? — https://www.trendmicro.com/ru_ru/what-is/attack-surface/external-attack-surface-management.html

[8] TAdviser: Чек-лист TAdviser — как выстроить управление внешней поверхностью атаки — https://www.tadviser.ru/index.php/Статья:Чек-лист_TAdviser

[9] RiskProfiler: The Evolution of External Attack Surface Management in 2025 — https://riskprofiler.io/easm-trends-2025/

[10] SecurityScorecard: Safeguarding Against Subdomain Takeover — https://securityscorecard.com/blog/safeguarding-against-subdomain-takeover/

[11] Virtual Cyber Labs: Subdomain Takeover — Understanding the Threat — https://virtualcyberlabs.com/subdomain-takeover-understanding-the-threat/

[12] Qualys TotalCloud: Subdomain Takeover Risk Detection (Keytos Research data) — https://blog.qualys.com/product-tech/2024/01/11/totalcloud-insights-crafting-effective-indicators-of-compromise-iocs-for-sub-domain-takeover-risk-detection

[13] MDN Web Docs: Subdomain takeover — https://developer.mozilla.org/en-US/docs/Web/Security/Subdomain_takeovers

[14] LockIP: Subdomain Hijacking — How Attackers Exploit Forgotten DNS Records (SubdoMailing) — https://www.lockip.net/blog/subdomain-hijacking-protection-guide

[15] Акрибия: Управление поверхностью атаки EASM (данные об открытых БД) — https://acribia.ru/services/external_attack_surface_management

[16] Verizon 2025 Data Breach Investigations Report — https://www.verizon.com/business/resources/reports/dbir/

[17] Enzoic: 2024 Verizon DBIR — Key Thoughts (default credentials) — https://www.enzoic.com/blog/2024-verizon-dbir/

[18] AEPD: Personal Data Breaches — Development and Pre-Production Environments — https://www.aepd.es/en/prensa-y-comunicacion/blog/data-breaches-development-and-pre-production-enviroments

[19] Entro Security: Applying Best Practices to Secure Staging Environments — https://entro.security/blog/securing-staging-environments-best-practices/

[20] UpGuard: Don't Use Production Data In Your Test Environment — https://www.upguard.com/blog/dont-use-production-data-in-your-test-environment

[21] Brandefense: Shadow IT And External Attack Surface — https://brandefense.io/blog/shadow-it-and-external-attack-surface-what-youre-missing/

[22] KeeperSecurity: Что такое теневые ИТ-ресурсы — https://www.keepersecurity.com/blog/ru/2024/01/08/what-is-shadow-it-and-how-can-organizations-eliminate-it/

[23] Positive Technologies: CODE RED 2026 — актуальные киберугрозы для российских организаций — https://ptsecurity.com/research/analytics/russia-cyberthreat-landscape-2026/

[24] Ведомости.Технологии: Упреждающая кибербезопасность — https://www.vedomosti.ru/technologies/trendsrub/articles/2025/12/08/1161313-zaschite-it-infrastrukturi

[25] BI.ZONE CPT: В BI.ZONE CPT добавлена метрика EPSS — https://bi.zone/news/v-bi-zone-cpt-dobavlena-metrika-epss-dlya-prioritizatsii-uyazvimostey/

[26] RTM Group: Новые штрафы за утечки ПДн (уголовная ответственность) — https://rtmtech.ru/articles/novye-shtrafy-za-utechki-pdn/

[27] Beyond Identity: Verizon DBIR 2025 — Access is Still the Point of Failure (third-party breaches) — https://www.beyondidentity.com/resource/verizon-dbir-2025-access-is-still-the-point-of-failure

[28] EASM СДЭК кейс — https://ovodov.su/easm-upravlenie-poverhnostiy-atak

[29] Kiteworks: Top 11 Data Breaches of 2024 (AT&T S3 bucket) — https://www.kiteworks.com/top-11-data-breaches-2024-risk-score/