“Если вы не можете предсказать, как будет эксплуатироваться система — взломают не её, а вашего пользователя. А его ответом станет ваш чек-лист.”
В индустрии информационной безопасности общий уровень риска часто оценивается по формальным показателям: пройдена сертификация ФСТЭК, сотрудники обучены по 152-ФЗ, доступы разграничены. Но реальная угроза редко бывает формальной. Она движется по самым неожиданным путям, которые редко попадают в контрольные списки. Вот один из таких путей, который привел к почти полному отключению сети крупной российской торговой компании.
Фон: успешная компания и ее модель защиты
Компания «РитэйлТех» (имя изменено) развивала сеть из более чем 500 точек продаж по стране. Её ИТ-инфраструктура была типичной для среднего бизнеса с амбициями: центральный офис в Москве, два дата-центра, распределённые склады и магазины, связанные через VPN. С точки зрения регуляторики всё было в порядке. Существовала система менеджмента безопасности информации (СМБИ) по требованиям 152-ФЗ, политики разграничения доступа, журналы учёта. Ключевые серверы были аттестованы по требованиям ФСТЭК, использовались сертифицированные средства защиты.
Команда безопасности состояла из восьми человек, которые занимались мониторингом SIEM, реагированием на инциденты и поддержанием СМБИ. Их основное внимание было направлено на периметр: сетевые экраны, система обнаружения вторжений, защита веб-приложений. Внутренние риски сводились к стандартным: увольняющимся сотрудникам отключали доступ, проводили ежегодное обучение по информационной безопасности.
Именно эта внешняя благополучность и стала первым условием инцидента. Защита была сфокусирована на известных векторах, но не на цепочке действий, которую может совершить рядовой сотрудник, не имеющий злого умысла.
Главный герой: не системный администратор, а инженер отдела автоматизации
Алексей (имя изменено) работал в отделе автоматизации бизнес-процессов. Его задача — настройка и поддержка ПО для управления товарными остатками, которое общалось со складами и магазинами. Для этого ему был предоставлен доступ к ряду внутренних систем и, что критически важно, к серверу, где хранились конфигурации сетевого оборудования — маршрутизаторов и коммутаторов.
Этот доступ не был ошибкой. По бизнес-логике, для автоматического обновления сетевых настроек при открытии новой точки требовался скрипт, который мог бы читать и записывать конфигурации. Алексей получил права на запись в конкретный каталог на этом сервере. Никто не задался вопросом, что будет, если скрипт, запущенный с его рабочей станции, начнёт не читать, а перезаписывать файлы массово. В политиках доступа было прописано «разрешено», но не было прописано «при каких условиях и с какими лимитами».
Его рабочая станция была стандартно защищена антивирусом и входила в домен. Однако на ней, как и у многих инженеров, для удобства работы были установлены несертифицированные утилиты и скриптовые оболочки. Один из таких инструментов стал точкой входа.
Цепочка событий: от задачи до каскадного отказа
Всё началось с рутинной задачи. Алексею поручили обновить параметры DHCP в конфигурациях для группы из 20 новых магазинов. Вместо ручного редактирования каждого файла он решил использовать ранее написанный PowerShell-скрипт, который должен был найти файлы по маске и заменить в них строку.
Ошибка в скрипте
Скрипт содержал логическую ошибку. Вместо поиска файлов по конкретной маске «store_new_*.cfg» он, из-за опечатки в переменной, искал файлы по маске «*.cfg». Это затронуло не 20 целевых файлов, а все 1800 файлов конфигураций на сервере, включая действующие конфигурации для всей сети.
Катастрофическая замена
Вторая часть скрипта выполняла замену текста. Планировалось заменить «dhcp-pool 10.10.1.0» на «dhcp-pool 10.10.5.0». Но из-за ошибки в регулярном выражении, строка замены оказалась пустой. В итоге, во всех обработанных файлах конфигураций строчки, содержащие настройки DHCP, были просто удалены. Файлы сохранились, но их содержимое стало невалидным для сетевого оборудования.
Автоматическое применение конфигураций
Здесь сработал второй элемент системы, о котором Алексей не подумал. На этом же сервере работал служба автоматического развертывания конфигураций (собственная разработка «РитэйлТех»). Её задача — каждые 15 минут проверять каталог на наличие изменённых файлов и отправлять их на соответствующее сетевое устройство. Это было сделано для ускорения развёртывания изменений.
Служба обнаружила массовое изменение сотен файлов, посчитала это плановым обновлением и начала процесс отправки. Через несколько минут первые коммутаторы в региональных складах получили «битые» конфигурации и перезагрузились для их применения. После перезагрузки, не найдя валидных настроек IP-адресации, устройства перешли в режим загрузки по сети или просто отказались поднимать интерфейсы. Связь начала пропадать каскадом.
Масштаб инцидента: не вирус, а тишина
В 11:30 по московскому времени в мониторинге начали массово «краснеть» датчики с периферии. Сначала пропала связь с удалёнными складами, затем перестали отвечать кассы в магазинах. К 11:45 отключились системы видеонаблюдения и контроля доступа в центральном офисе. SIEM зафиксировал не атаку, а аномалию — тысячи событий «link down» и «device unreachable».
Команда безопасности изначально предположила масштабную DDoS-атаку или действие вредоносного ПО. Были запущены процедуры по изоляции периметра. Однако отключение внешних каналов не остановило процесс — «заражение» было уже внутри. Сетевые инженеры, пытаясь подключиться к ключевым коммутаторам, обнаружили, что те недоступны по IP.
Только к 12:30, сопоставив временные метки, один из системных администраторов обратил внимание на лог службы развёртывания конфигураций, которая показала массовую отправку файлов в 11:28. Была найдена корневая причина.
Восстановление: не из резервной копии, а вручную
Здесь проявилась вторая уязвимость. Резервные копии конфигураций сетевого оборудования делались ежедневно в 02:00 и хранились на том же самом сервере. Скрипт Алексея, обработав все файлы «*.cfg», испортил и их. Архивные копии за прошлые дни существовали, но процесс их восстановления на более чем 1500 устройств вручную занял бы дни.
Команде пришлось действовать в обход процедур. Они физически отключили сервер конфигураций от сети, чтобы остановить службу развёртывания. Затем, используя консольный доступ через out-of-band-каналы (которые были настроены не везде), начали вручную загружать валидные конфигурации на ключевые магистральные устройства, восстанавливая островки связи. Работали по географическому принципу, начиная с дата-центров.
Полное восстановление базовой связности заняло 14 часов. Некоторые удалённые магазины оставались отрезанными более суток. Финансовые потери от простоя торговых точек, срыва поставок и экстренной работы специалистов оценили в сумму, многократно превышающую годовой бюджет всего отдела информационной безопасности.
Что было нарушено на самом деле?
Формально инцидент не подпадал под классическое определение «утечки» или «взлома» по 152-ФЗ. Не было несанкционированного доступа извне, утечки персональных данных. Однако были нарушены базовые принципы безопасности, заложенные и в регуляторные требования.
- Принцип минимальных привилегий был применён формально. Алексей получил доступ, необходимый для работы, но не были установлены механизмы, ограничивающие массовость или критичность его действий (например, квоты на изменение файлов, mandatory access control).
- Сегрегация обязанностей (SoD) отсутствовала. Один сотрудник мог изменить конфигурацию и тут же её применить через автоматическую службу. Не было стадии проверки или утверждения.
- Управление изменениями не распространялось на «скриптовую» автоматизацию. Изменение, вносимое кодом, не проходило через стандартный процесс Change Management.
- Резервное копирование было организовано без учёта риска повреждения источника. Резервные копии хранились в той же среде, что и оригиналы, и были уязвимы к тому же воздействию.
- Мониторинг аномальной активности был настроен на поиск внешних угроз, но не на отслеживание аномально высокого количества операций записи с одной учётной записи за короткий промежуток времени.
Выводы и превентивные меры
Этот кейс — не про злого сотрудника, а про системные слепые зоны, которые создаются самими защитниками. После инцидента в «РитэйлТех» внедрили ряд мер, выходящих за рамки чек-листов.
1. Контроль привилегий для автоматизации
Права для служебных учётных записей и учётных записей разработчиков были пересмотрены. Для операций, потенциально затрагивающих массовые конфигурации, ввели систему двух ключей: скрипт мог подготовить изменения, но для их применения требовалось одобрение от второй учётной записи (например, сетевого инженера). Также внедрили систему контроля сессий для привилегированных действий, записывающую все операции в защищённый лог.
2. Изолированная среда для управления конфигурациями
Была создана отдельная, сильно изолированная виртуальная среда для хранения мастер-конфигураций и средств их развёртывания. Доступ к этой среде осуществлялся только через выделенные станции с жёстким контролем устанавливаемого ПО. Сама служба развёртывания была модифицирована: перед применением конфигурации она проверяла её валидность через синтаксический анализатор, а также требовала обязательной цифровой подписи для любого файла, поступающего в рабочую директорию.
3. Иммунная система резервного копирования
Схему резервного копирования перестроили по принципу «3-2-1», адаптированному для конфигураций. Появились три копии: операционная (на изолированном сервере), ежедневная (на ленточном накопителе, отключённом от сети) и недельная (удалённая, в другом дата-центре). Процедура восстановления была отработана на учебных стендах.
4. Мониторинг поведенческих аномалий
В SIEM добавили правила, отслеживающие не только известные угрозы, но и поведенческие шаблоны: например, более 100 операций записи в файловую систему с одной учётной записи за 5 минут, или попытка доступа к каталогу с конфигурациями с рабочей станции, не входящей в специальный белый список. Такие события стали поднимать инциденты с высоким приоритетом.
5. Культура «безопасной автоматизации»
Для инженеров и разработчиков провели отдельные тренинги. Их суть: автоматизация не отменяет требования безопасности, а ужесточает их. Любой скрипт, работающий с производственной средой, должен проходить ревью кода на предмет потенциально опасных операций (широких масок, рекурсивных удалений, отсутствия обработки ошибок) и тестироваться на выделенном стенде. Это внедрили в процесс CI/CD.
Инцидент показал, что самый опасный вектор — не внешний хакер, а легитимный привилегированный доступ, соединённый с ошибкой и автоматизацией без защитных ограничений. Защита строится не только на запретах, но и на понимании того, как обычные рабочие процессы могут превратиться в канал полного отказа системы. В российском контексте, где всё больше компаний сталкивается с требованиями ФСТЭК и 152-ФЗ, этот кейс — напоминание, что формальное соответствие часто остаётся на поверхности. Реальная устойчивость начинается, когда вы анализируете не только то, кто имеет доступ, но и что он может сделать с этим доступом в условиях человеческой или программной ошибки.