«У нас нет выхода. Мы живём среди цифровых руин, которые строили по принципу «работает — уже хорошо». Защита таких систем — не инженерная задача, а археологическая работа со следами чужих ошибок. Единственный выход — выстроить вокруг этих систем слой контрольно-заградительной архитектуры, которая превращает их хаос в управляемый хаос.»
Легаси: наследство, от которого не отказаться
Сколько в российских госучреждениях, на предприятиях энергетики и транспорта работает систем, написанных 15, 20, а то и 30 лет назад? Подсчитать невозможно. Это не всегда физически устаревшие компьютеры, хотя и такое бывает. Чаще — критический софт, который невозможно переписать с нуля, не остановив жизненно важные процессы.
Представьте автоматизированную систему диспетчеризации теплоснабжения города, написанную на Delphi в начале нулевых. Её исходный код утерян, документация устарела, а автор давно уволился. Система общается с контроллерами через закрытый протокол, который понимают только эти старые библиотеки. Она не поддерживает современную аутентификацию, не пишет детальные логи, её сетевой стек уязвим. Но она обеспечивает тепло в домах. Заменить её — многолетний проект с непредсказуемым результатом. А пока проект идёт, её нужно как-то защитить.
Принцип проектирования: «Функциональность прежде всего»
В эпоху, когда писались многие из этих систем, угрозы выглядели иначе. Не было массовых атак через интернет, не было ransomware, не было спонсируемых государством хакерских групп. Безопасность сводилась к физическому доступу к серверу и паролю на дискету. Сеть считалась доверенной средой. Поэтому архитектура строилась по принципу максимальной связности и удобства для разработчика.
Например, промышленная система управления часто предполагала, что все её компоненты — инженерные рабочие станции, сервера управления, контроллеры — находятся в одной плоской сети. Компоненты общались по протоколам без шифрования и аутентификации, потому что считалось, что если злоумышленник уже внутри сети, то игра проиграна. Сегодня такое архитектурное решение — мечта для злоумышленника, который проник в сеть через фишинг.
Экономика против безопасности
Стоимость полного рефакторинга или замены legacy-системы астрономически высока. Она складывается не только из лицензий на новое ПО и оплаты труда программистов. Основные затраты — это:
- Анализ и реверс-инжиниринг существующей логики, особенно в отсутствие документации.
- Параллельный запуск старой и новой систем для верификации результатов.
- Остановка критического процесса на время переключения. Для завода, электростанции или банка каждая минута простоя — миллионные убытки.
- Обучение персонала, который десятилетиями работал со старой системой.
На этом фоне вложения в средства защиты, даже дорогие, выглядят как разумный компромисс. ФСТЭК-сертифицированный межсетевой экран и SIEM для мониторинга аномалий, это капитальные затраты, но они не требуют остановки основного бизнес-процесса.
Регуляторный прессинг: 152-ФЗ и требования ФСТЭК
Законодательство не делает скидку на возраст системы. Если в ней обрабатываются персональные данные или она входит в критическую информационную инфраструктуру, она должна соответствовать требованиям. У ФСТЭК нет отдельного стандарта для «старых, но любимых» систем.
Это создаёт парадоксальную ситуацию: саму систему нельзя быстро изменить, но вокруг неё нужно выстроить защитный периметр, который компенсирует её врождённые недостатки. Фактически, регуляторика заставляет создавать «систему в системе».
| Недостаток legacy-системы | Компенсирующая мера по 152-ФЗ/требованиям ФСТЭК |
|---|---|
| Нет разделения прав доступа внутри приложения | Внедрение системы строгой аутентификации и авторизации на уровне шлюза (VDI, прокси). Пользователи получают доступ не к системе напрямую, а к её интерфейсу через защищённый канал с контролем сессий. |
| Нет журналирования (логирования) действий | Развёртывание сетевого анализатора трафика или агента на хосте, который косвенно логирует активность (например, обращения к портам, вызовы процессов) и отправляет события в SIEM. |
| Использование небезопасных или устаревших протоколов (например, Telnet, SNMP v1) | Выделение системы в изолированный сегмент сети. Трафик между сегментами проходит через прокси-серверы, которые «обёртывают» старый протокол в VPN или TLS-тоннель. |
| Невозможность установки агентов защиты (HIPS, антивирус) | Применение сетевых средств обнаружения вторжений (NIDS), сканирование уязвимостей на уровне сети, строгий контроль за целостностью исполняемых файлов на файловом уровне. |
Стратегия «обёртывания»: как защитить неисправимое
Тактика защиты legacy сводится не к исправлению её кода, а к ограничению её взаимодействия с миром. Это контролируемая изоляция.
Сетевая сегментация и микросегментация
Первое и главное действие — вытащить систему из общей плоской сети. Её помещают в отдельный VLAN или даже физически изолированный сегмент. Доступ в этот сегмент разрешён только с определённых административных рабочих мест через jump-сервер. Все попытки соединения извне и изнутри логируются межсетевыми экранами нового поколения.
Проксирование и шлюзы доступа
Прямой доступ к интерфейсу старой системы запрещён. Вместо этого пользователи подключаются к защищённому веб-шлюзу или решению для виртуальных рабочих столов. Этот шлюз выступает посредником: он отрисовывает интерфейс legacy-системы у пользователя, а все команды передаёт дальше. Таким образом, на самой старой системе не появляются новые учётные записи, а все сессии можно контролировать и записывать.
Мониторинг аномалий на уровне потока данных
Если нельзя понять, что делает система изнутри, можно понять, как она общается. Анализ сетевого трафика (NetFlow, пакетный анализ) позволяет выявить аномалии: нехарактерные объёмы данных, подключения к нестандартным портам, связи с подозрительными IP-адресами. Например, если система управления станком, которая обычно передаёт несколько килобайт в час, вдруг начинает отправлять мегабайты данных наружу, это сигнал.
Риски и пределы такой защиты
Защита «снаружи» не устраняет уязвимости «внутри». Если злоумышленник каким-то образом обойдёт периметр (например, через инсайдера с легитимным доступом к шлюзу или через ранее неизвестную уязвимость в самом прокси), он окажется внутри незащищённой системы. Наш защитный слой становится одноразовым барьером.
Кроме того, такая архитектура добавляет сложности и точки отказа. Теперь для работы старой системы должны работать ещё шлюз, межсетевой экран, система мониторинга. Это увеличивает затраты на эксплуатацию и требует новых компетенций у администраторов.
Это навсегда?
Защита legacy — не конечное состояние, а длительный переходный этап. Его цель — не увековечить старую систему, а обеспечить её безопасную работу, пока идёт разработка замены или глубокой модернизации. Этот этап может длиться годами. Ключевая задача — использовать этот период для накопления данных: как система используется, какие процессы в ней критичны, какие сценарии общения нормальны. Эти данные станут техзаданием для новой системы, которая должна будет проектироваться уже с учётом безопасности изначально.
Пока же мы вынуждены строить крепости вокруг домов с картонными стенами. Это нелогично, затратно, но это единственный способ жить в городе, который построили до изобретения кирпича.