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

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

.

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

Как устройство получает право действовать самостоятельно

Автономность устройства обеспечивается жёсткой алгоритмической логикой. Проблема возникает не из-за сложности алгоритма, а из-за того, что его работа изолирована от операционного контекста и не требует внешнего подтверждения для критических операций.

Типичная последовательность действий умного устройства выглядит так:

  • Сбор данных. Сенсоры или камеры фиксируют состояние: уровень запасов, показания датчиков, остатки на складе.
  • Анализ по правилам. На основе встроенных пороговых значений и исторических данных система определяет необходимость действия.
  • Формирование команды. Система готовит транзакцию, заявку или управляющий сигнал для внешнего сервиса.
  • Исполнение. Используя сохранённые учётные данные или доступы, устройство самостоятельно завершает операцию.

Сбой происходит на последнем этапе: между принятием решения и его исполнением отсутствует обязательный этап санкционирования. В протоколе работы нет обязательного контроля (mandatory control), требующего вмешательства ответственного лица.

От бытового сценария к рискам в госсекторе и КИИ

В системах, подпадающих под действие регуляторных требований, аналогичный сценарий классифицируется как несанкционированное воздействие. Рассмотрим конкретные параллели.

Автоматизация государственных закупок (44-ФЗ)

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

Автоматизированные системы управления технологическими процессами (АСУ ТП)

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

Технические причины: игнорирование контроля целостности

Борьба с подобными инцидентами, это не отказ от автоматизации, а внедрение архитектурных принципов контроля целостности (integrity control) и контекста.

  1. Принцип разделения полномочий (двух ключей). Любое критическое действие должно санкционироваться из двух независимых источников. Например, сигнал от автоматизированной аналитики + явное подтверждение оператора через отдельный, изолированный канал связи. В бытовом примере — push-уведомление в приложении, требующее подтверждения.
  2. Контекстные ограничения и белые списки. Автоматизированной системе нельзя предоставлять неограниченные полномочия. Должны быть установлены жёсткие политики:
    • Лимит на сумму автономной транзакции.
    • Белый список разрешённых к автоматическому заказу номенклатур или категорий команд.
    • Запрет на исполнение операций нового типа без обязательного ручного подтверждения при первом обращении.
  3. Выявление аномалий поведения (UBA). Система должна отслеживать отклонения от базовых паттернов поведения. Внезапный заказ непрофильной дорогостоящей позиции или отправка команды в нештатное время, это аномалия. Такие операции должны блокироваться с обязательным созданием инцидента для расследования.

Требования регуляторов: как это должно работать

Отечественные руководящие документы и стандарты в области информационной безопасности содержат требования, прямо направленные на предотвращение описанных рисков.

Документ / Принцип Применение к сценарию
РД ФСТЭК «Комплекс мер по защите информации…» Требует обязательной регистрации событий безопасности. Автоматическое действие системы должно протоколироваться с указанием программного инициатора (скрипт, служба), а не просто от имени пользователя, от чьего имени она работает.
Приказ ФСТЭК № 31 (требования к СЗИ в ГИС) Акцент на неотказуемости и целостности. После критического действия должно оставаться криптографически обеспеченное доказательство того, что именно санкционировало операцию. Простой записи в лог недостаточно.
152-ФЗ (обработка ПДн) Платёжные реквизиты — персональные данные. Их автоматическая обработка системой должна соответствовать заранее определённым и заявленным целям. Автономная транзакция без уведомления субъекта ПДн может трактоваться как нарушение.
Безопасность критической информационной инфраструктуры (КИИ) Требования к АСУ ТП предписывают обязательное наличие контура ручного управления и подтверждения для команд, приводящих к изменению технологического режима или останову.

Итог: архитектура подотчётности вместо слепой автоматизации

Сценарий с холодильником обнажает фундаментальную ошибку проектирования многих современных систем: погоня за полной автономностью в ущерб принципу security-by-design.

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

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

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

Оставьте комментарий