Александр Войновский, ПАО «Газпром нефть»: Экономить на требованиях безопасности в промышленной среде — не лучшая стратегия

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

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

Ключевой момент — точка принятия компромиссов. Соответствие стандартам проверяется на архитектурном комитете вместе с остальной архитектурой решения, а не на отдельном согласовании с подразделением ИБ в конце проекта. Если типовое решение не подходит, отклонение оформляется как отдельное решение, а не как обход стандарта. Это переводит обсуждение из плоскости «безопасность против проекта» в плоскость управленческих решений, к которым при необходимости можно вернуться.

Александр Войновский: Почти любая корпоративная система, так или иначе, связана с производственным контуром — данными, интеграциями, доступом к смежным системам. Оценивать ее изолированно нельзя: система, которая сама по себе выглядит некритичной, может оказаться входной точкой в цепочке, где последствия измеряются уже не только деньгами. Кроме того, значительная часть инфраструктуры попадает под действие 187-ФЗ и требований ФСТЭК, где состав мер защиты определяется не архитектором, а категорией объекта.

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

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

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

Александр Войновский: Формулировка «никому не доверять» описывает скорее следствие, чем суть подхода. С архитектурной точки зрения Zero Trust означает отказ от сетевого расположения как источника доверия. Иными словами, исчезает допущение, что трафик внутри периметра автоматически считается легитимным только потому, что находится в доверенной зоне.

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

Zero Trust нельзя внедрить одним проектом или купить в виде готового продукта. Это целевая модель, к которой инфраструктура приводится постепенно

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

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

Александр Войновский: Полностью внедрить Zero Trust поверх существующего ИТ-ландшафта не получится. Многие меры действительно можно реализовать достаточно быстро: единый вход, двухфакторную аутентификацию, проверку устройств, шлюзы перед приложениями и сегментацию сети. Это уже дает заметный эффект. Однако когда речь заходит о ключевом принципе Zero Trust — проверке каждого запроса, — возникают ограничения. Старые системы зачастую просто не умеют работать по такой модели. Приложение, которое доверяет всему трафику из внутренней сети, останется слепым пятном независимо от того, сколько защитных контуров вокруг него выстроено.

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

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

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

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

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

Основа такого подхода — единая точка входа. Все обращения к ИИ-модели должны проходить через корпоративный шлюз, иначе компания теряет контроль и возможность аудита. На уровне шлюза работает механизм проверки запросов, который выявляет чувствительные данные и при необходимости маскирует или блокирует их передачу.

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

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

Александр Войновский: Задача здесь формулируется несколько иначе: не просто «встроить ИИ вместо внешних сервисов», а предоставить сотрудникам внутри корпоративного ландшафта тот же уровень удобства и скорости работы, к которому их уже приучили внешние продукты. Сложность в том, что внешний сервис конкурирует не столько качеством модели, сколько пользовательским опытом: быстрые ответы, отсутствие сложных настроек и согласований. Именно с этим сотрудники будут сравнивать внутренний инструмент.

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

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

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

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

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

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

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

Кроме того, появляется новый класс угроз. Модель воспринимает данные как инструкции, поэтому текст, встроенный в письмо, документ или другой источник данных, способен изменить ее поведение и подменить намерение пользователя. Именно поэтому права доступа должны быть организованы таким образом, чтобы даже успешная подмена не приводила к критическим последствиям.

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

Дополнительным фактором остается высокий уровень защищенности таких сред: контуры АСУ ТП, как правило, изолированы и имеют дополнительные ограничения на доступ и взаимодействие.

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