Владимир Перминов: "Как обеспечить безопасный информационный обмен на крупных предприятиях и объектах КИИ"
Информационный обмен давно стал неотъемлемой частью работы крупных предприятий, но вместе с новыми возможностями появились и новые риски. Рост числа кибератак, цифровизация, новые требования регуляторов и необходимость соблюдения требований ФСТЭК меняют подходы к защите данных на крупных предприятиях и объектах КИИ. О том, почему привычные методы уже не всегда работают, какие риски компании часто недооценивают и каким будет развитие защищенного информационного обмена в ближайшие годы, поговорили с Владимиром Перминовым, заместителем директора по развитию бизнеса компании «АйТи Бастион».
Почему меняются требования
RUБЕЖ: Почему сегодня безопасный информационный обмен становится одной из важнейших задач кибербезопасности крупных предприятий и объектов КИИ?
Владимир Перминов: Еще недавно безопасность строилась вокруг простой картины: есть периметр, за ним свои, снаружи чужие, а на границе стоит межсетевой экран. Сегодня эта модель уже не работает. Технологическая сеть должна отдавать данные в аналитику, завод обменивается информацией с головным офисом и облаком, подрядчики подключаются к внутренним ресурсам. Обмен превратился из отдельной операции в постоянный фон - и каждый такой канал становится потенциальной точкой входа. Запретить его нельзя, потому что на нем держится работа, значит, нужно уметь его контролировать.
Параллельно ужесточился и регулятор. Контроль потоков между сегментами разной значимости теперь прямо прописан - в приказе №239 по КИИ, №31 по АСУ ТП, а с марта этого года и в новом приказе №117, который заменил семнадцатый и распространил обязательные меры на более широкий круг систем. То, что вчера было желательной практикой, сегодня стало требованием, за которое отвечаешь на проверке.
И характер атак изменился. Все чаще проникают не через лобовой взлом периметра, а через доверенные каналы - вместе с файлом от подрядчика или с обновлением. То есть именно через обмен. Получается, что самое нужное бизнесу место оказывается и самым уязвимым.
RUБЕЖ: Какие риски при организации информационного обмена компании чаще всего недооценивают?
В. Перминов: Чаще всего недооценивают обратный канал. Типичный сценарий: ставится задача вывести данные из закрытого технологического контура наружу, в корпоративный, для этого применяется однонаправленная передача - и на этом считают вопрос закрытым. Однако односторонний вывод отрезает и легальную возможность передать что-либо обратно в контур, а передавать туда нужно регулярно: обновления прикладного программного обеспечения и операционных систем, антивирусные базы и сигнатуры средств защиты, управляющие команды и конфигурации. Потребность в этом не исчезает, а при отсутствии штатного канала ее закрывают подручными средствами - съемным носителем, отдельным ноутбуком, временным исключением в межсетевом экране. В результате ради формальной изоляции создается канал, который на практике опаснее контролируемого двустороннего обмена. С этим же связаны и завышенные ожидания от «диодов»: однонаправленность решает лишь часть задач, тогда как предприятию, как правило, необходим управляемый обмен в обе стороны.
Вторая слепая зона - доверие к «своим» каналам: флешкам, файловым шарам между отделами, интеграционным шинам. Их по привычке считают внутренними и безопасными, а именно по ним чаще всего и заезжает вредонос или утекает лишнее.
И почти всегда недооценивают контроль содержимого. Компании проверяют, что файл ушел по правильному маршруту, но не смотрят, что внутри - а там может быть и зловред, и данные, которым за периметром делать нечего. Сюда же добавлю целостность: про конфиденциальность думают всегда, а про то, что данные по дороге могут подменить, - гораздо реже. Хотя для АСУ ТП искаженная команда порой опаснее любой утечки.
RUБЕЖ: Какие изменения последних лет сильнее всего повлияли на требования к защите информационного обмена: рост кибератак, импортозамещение, цифровизация или что-то другое?
В. Перминов: Здесь трудно выделить один фактор - они усиливают друг друга. Атак стало больше, и бьют они прицельнее по промышленности и КИИ, поэтому фокус сместился с охраны периметра на то, что происходит внутри, между сегментами. Цифровизация умножила число связей: где раньше был один канал, сегодня десятки интеграций, и каждую нужно описать и проконтролировать.
Импортозамещение поменяло не столько сами требования, сколько инструменты для их выполнения - теперь это сертифицированные отечественные средства, реализованные на доверенных операционных системах. Astra Linux, Ред ОС, Альт, Основа – выбор большой. Это дисциплинирует рынок и подтолкнуло появление зрелых российских решений там, где раньше преобладал импорт.
Но сильнее всего, на мой взгляд, повлияла регуляторика. Приказ №117, вступивший в силу 1 марта 2026 года, и обновленные методические документы ФСТЭК не просто перечислили меры - они сделали контроль потоков обязательным и проверяемым. А это уже требует перестраивать саму архитектуру обмена, а не докупать очередное средство.
Где возникают основные сложности
RUБЕЖ: Бизнес заинтересован в быстром обмене данными, а служба информационной безопасности - в максимальном контроле. Как найти баланс между скоростью работы и безопасностью?
В. Перминов: Я не считаю, что здесь есть настоящий конфликт - он возникает только при неудачной архитектуре. Бизнес тормозит не контроль как таковой, а ручные согласования, когда на каждый файл нужно, чтобы человек посмотрел и нажал «разрешить». Уберите это звено - и хорошо настроенный контроль, наоборот, ускоряет обмен.
Суть в том, чтобы один раз договориться: какие данные, между какими контурами и по каким маршрутам могут передаваться. Зафиксировали это правилами - и дальше рутину выполняет машина, мгновенно и по заранее одобренным политикам. Человек подключается только к тому, что выбилось из правил.
На этом принципе и стоят решения класса СКИО - средства контролируемого информационного обмена. Данные идут по правилам без оператора, но каждое действие проверяется и логируется. Наш «Синоникс» из этого класса и сертифицирован ФСТЭК, поэтому одним решением можно и ускорить обмен, и закрыть обязательные меры контроля потоков. Безопасность здесь не отбирает скорость, а идет с ней в комплекте - и заодно ложится в требования приказов.
RUБЕЖ: Где проходит граница между разумными ограничениями и мерами безопасности, которые начинают замедлять бизнес-процессы?
В. Перминов: Признак простой: разумное ограничение всегда можно объяснить - от какого риска оно защищает и на какое требование опирается, тот же приказ №117 или №239. Как только вместо ответа звучит «на всякий случай», перед вами, скорее всего, избыточная мера, которая либо дублирует уже работающий контроль, либо блокирует процесс там, где хватило бы проверки.
На практике я оцениваю так: если контроль добавляет к обмену секунды и все логируется - это нормальная плата за безопасность. Если же каждую типовую операцию гоняют через ручное согласование и штатное дело растягивается на часы - значит, перестарались. И тут появляется побочный эффект пострашнее: сотрудники начинают искать обходные пути. Такие самодельные «серые» каналы опаснее, чем отсутствие ограничения. Поэтому границу я провожу не по строгости меры, а по ее адресности и по тому, можно ли отдать ее автомату.
RUБЕЖ: Какие процессы информационного обмена уже можно безопасно автоматизировать, а где участие человека по-прежнему остается необходимым?
В. Перминов: Автоматизировать можно все, что укладывается в четкое правило: типовой файловый обмен с проверкой по имени, типу, размеру и подписи; антивирус и DLP на содержимое; передачу телеметрии из технологического контура в аналитику; регламентную синхронизацию между площадками. Здесь машина не просто быстрее - она надежнее, потому что не делает исключений и не устает к концу смены.
Стоит развеять одно заблуждение: сам шлюз обмена не обязан уметь все внутри себя. В нормальной архитектуре проверку содержимого - антивирус, песочницу, DLP - выносят на отдельные серверы и подключают по протоколу ICAP. Это правильно: шлюз отвечает за маршруты и правила, а тяжелый анализ делают специализированные движки.
Человек незаменим там, где нужно не сверить по шаблону, а подумать: нестандартный запрос, разбор инцидента, новый тип данных, который еще никто не классифицировал, самые критичные контуры - гостайна, наиболее значимые объекты КИИ. Оставлять решение за людьми здесь - не отсталость, а осознанный выбор. Цель ведь не убрать человека из процесса, а снять с него рутину и оставить то, за что действительно нужно отвечать.
Как меняется подход к защите
RUБЕЖ: Как использование генеративного искусственного интеллекта влияет на организацию защищенного информационного обмена? Какие новые риски и возможности появляются у компаний?
В. Перминов: Самое болезненное - генеративный ИИ незаметно открыл новый массовый канал утечки. Сотрудник копирует в чат с моделью фрагмент документа, кода или данных заказчика, и информация уходит за периметр по каналу, которого классическая DLP почти не видит. Добавьте сюда «теневой ИИ», когда сервисами пользуются в обход согласований, и обучение чужих моделей на ваших чувствительных данных. По сути, появился еще один выход наружу, который нужно ставить под тот же контроль потоков, что и все остальное.
Есть и обратная сторона - атакующим ИИ тоже помог. Правдоподобный фишинг и вредоносный код теперь создаются дешево и быстро, а значит, содержимое, приходящее по каналам обмена, стало опаснее и его труднее отличить от легитимного. Это лишний повод проверять именно содержимое, а не только маршрут.
При этом ИИ помогает и защите - разбирать логи обмена, ловить аномалии в потоках, ускорять классификацию для DLP. Для КИИ рецепт тут простой: держать ИИ-инструменты в изолированном доверенном контуре и жестко контролировать, что пересекает его границу. И мы снова упираемся в ту же задачу управляемого обмена, только теперь между контуром ИИ и остальной инфраструктурой.
RUБЕЖ: Как сегодня должен быть организован безопасный обмен данными с подрядчиками, филиалами и внешними организациями? Изменились ли требования к этим процессам за последние годы?
В. Перминов: Изменилось главное - отношение к «доверенным» сторонам. Раньше подрядчику выдавали VPN и, по сути, впускали в сеть под честное слово. Сегодня так нельзя: цепочка поставок стала одним из основных маршрутов атак, а приказы №239 и №117 прямо подразумевают контроль подключений внешних сторон, а не доверие к ним. И филиал - тоже не автоматически «своя» сеть, а внешний участник по отношению к критичному сегменту.
Правильная организация выглядит так: не открывать контрагенту часть сети, а дать ему выделенный контролируемый шлюз и ровно тот канал, который нужен под конкретную задачу. Каналов должно быть минимум, содержимое проверяется в обе стороны, и все пишется в журнал - чтобы на проверке было чем подтвердить, кто, что и куда передавал.
Это как раз ниша, ради которой средства контролируемого обмена и существуют. В нашей практике с «Синониксом» подключение подрядчиков и филиалов через такой шлюз - один из самых частых сценариев: он сокращает поверхность атаки и одновременно дает аудируемость, которую регулятор ожидает от систем категории КИИ.
RUБЕЖ: Какие подходы или технологии, на ваш взгляд, будут определять развитие защищенного информационного обмена в ближайшие три-пять лет?
В. Перминов: Я бы выделил несколько ключевых тенденций, которые уже сегодня меняют подход к защищенному информационному обмену и будут определять развитие этого направления в ближайшие годы. Первое - контролируемый обмен оформляется в отдельный класс средств (СКИО) и вытесняет узкое понимание «диода как железа». Здесь важный момент, вокруг которого много мифов: регулятор не требует, чтобы однонаправленность была именно аппаратной. В приказах №117 и №239 «средства однонаправленной передачи» указаны как альтернатива межсетевому экрану, а физическая изоляция прописана отдельно и применяется при необходимости. Жесткий физический разрыв обязателен в основном там, где речь о гостайне. Поэтому рынок закономерно смещается к программно-контролируемым потокам - гибкие правила плюс сертификация по уровню доверия.
Рядом идет zero trust между сегментами: отказ от установки «внутри все свое» в пользу проверки каждого взаимодействия. И контентная фильтрация нового поколения - DLP, которая работает на потоке в реальном времени и подкреплена ИИ, а не разбирает логи задним числом. Все это на отечественных доверенных платформах, что уже давно не мода, а условие.
Если коротко, вектор такой: от охраны границы - к управлению потоками, от «прошло или не прошло» - к пониманию, что именно прошло, и от аппаратных ограничений - к программным, но сертифицированным и доказуемым правилам.
Что будет дальше
RUБЕЖ: Если бы сегодня перед вами стояла задача выстроить систему защищенного информационного обмена на крупном предприятии с нуля, какие три принципа вы считаете наиболее важными?
В. Перминов: Если говорить о базовых принципах построения защищенного информационного обмена, то я выделил бы три ключевых. Первый принцип - запрещено все, что явно не разрешено. Архитектуру нужно проектировать от сегментов и связей между ними, сразу под категорирование по приказам №239, №117 и №31: какие контуры есть, какой они значимости, какие потоки между ними допустимы. Любой обмен идет по явному правилу и полностью логируется. Это фундамент, без которого дальше двигаться бессмысленно.
Второй - смотреть не только куда идет файл, но и что внутри. Проверить маршрут мало; нужно убедиться, что нет ни вредоносного кода, ни данных, которым нельзя наружу, и что по дороге ничего не подменили. На практике это значит связать шлюз обмена с антивирусом, песочницей и DLP - теми же ICAP-серверами - и обязательно контролировать целостность.
Третий принцип может показаться неожиданным: система должна быть не только соответствующей требованиям, но и удобной. Сертифицированные средства и прозрачность для аудита - это база. Но если система сложна в эксплуатации, ее начнут обходить, и самая строгая на бумаге защита посыплется. Поэтому понятные правила и разделение полномочий между людьми для меня такой же принцип, как первые два. Безопасность, которую неудобно соблюдать, попросту не соблюдают.
Читайте также: Виктор Виноградов: "Правило 3-2-1 не устарело — устарело представление, что его достаточно"
Благодарим за оставленный Вами отзыв! Мы стараемся становиться лучше!
Потребление энергии дата-центрами в РФ выросло на треть
«Облако КИИ» компании РТК-ЦОД прошло сертификацию по стандарту безопасности PCI DSS
Дефицит инженеров по «железу» на фоне переизбытка программистов: кто будет строить инфраструктуру для бума нейросетей

