Почти на каждом производстве можно услышать знакомую фразу: “У нас один инженерный логин на смену, так удобнее”. Удобнее - да, до первого инцидента. Потом выясняется, что никто не может точно сказать, кто и когда менял уставку, отключал защиту или правил конфигурацию. Для АСУ ТП это уже не бытовая небрежность, а прямой риск для безопасности, качества и расследований.
RBAC в OT нужен не для “галочки по кибербезу”, а для нормальной управляемости. Когда у каждого действия есть роль и персональная учетная запись, система становится предсказуемой: меньше случайных ошибок, меньше серых зон в ответственности и быстрее разбор проблем.
Короткий ответ
Рабочая модель RBAC для АСУ ТП строится вокруг трех принципов: минимум прав по роли (least privilege), разделение учетных записей по задачам и обязательный аудит изменений. Общие пароли в этой модели несовместимы с эксплуатационной надежностью.
Почему “общие пароли” опаснее, чем кажется
Проблема общих учеток не только в том, что их могут узнать лишние люди. Главный ущерб - потеря персональной ответственности. Когда под одним логином работают пять человек, журнал событий формально есть, но юридически и операционно он бесполезен.
Вторая проблема - неконтролируемое расширение прав. “Временный” доступ инженера часто остается навсегда, и через полгода операторская станция внезапно имеет административные возможности, которые никто уже не может объяснить.
Least privilege в цеховой практике
Принцип наименьших привилегий в OT не означает “всех всё запретить”. Он означает, что каждая роль получает ровно тот набор действий, который нужен для ее ежедневной работы, и не больше.
Оператору не нужен доступ к изменению логики ПЛК. Инженеру смены не нужен постоянный доступ к администрированию домена. Администратору не нужен доступ к технологическим операциям как к рутинной задаче. Когда эти границы размыты, любой человеческий фактор становится дороже.
Разделение учеток: личная, сервисная, аварийная
Нормальная схема обычно включает три типа учетных записей:
•личные - для реальной работы человека по роли;
•сервисные - для интеграций и автоматических задач;
•аварийные (break-glass) - строго под процедуру, с отдельным журналированием и последующим разбором.
Ключевая мысль: сервисная учетная запись не должна превращаться в “универсальный мастер-ключ”, а аварийная - использоваться как “быстрый путь” в обычную смену.
Временное повышение прав: как сделать безопасно
На производстве бывают задачи, где инженеру действительно нужен расширенный доступ. Это нормально. Ненормально - выдавать его бессрочно.
Рабочий подход: доступ повышается по заявке, на ограниченное время, с понятной целью и обязательным логированием действий. После окна работ права автоматически возвращаются к базовому профилю. Так команда сохраняет гибкость, не ломая безопасность.
Аудит: журнал должен быть пригоден для расследования
В контуре RBAC аудит отвечает на простой вопрос: кто, что, когда и в каком контексте сделал. Если в журнале нет связки с персональной учеткой и изменяемым объектом, это не аудит, а шум.
Минимально полезный аудит фиксирует:
•входы и неудачные попытки аутентификации;
•изменения прав и ролей;
•критичные действия в SCADA/PLC (уставки, режимы, блокировки);
•использование аварийных учеток;
•экспорт и изменения конфигураций.
Таблица ролей и типовых разрешений
Ниже базовая матрица, которую можно адаптировать под конкретный объект.
Как внедрять RBAC без конфликта с производством
Самая частая ошибка - пытаться “сегодня вечером выключить все общие учетки”. Это вызывает саботаж и риск для смены. Лучше идти поэтапно: сначала инвентаризация текущих доступов, затем запуск персональных учеток по критичным ролям, потом контроль временных повышений и только после этого жесткая очистка исторических исключений.
Если параллельно есть обучение смен и понятный канал эскалации, RBAC обычно принимается без болезненного сопротивления.
Где уместен СТАБУР
В многоплощадочных проектах ключевую роль играет единый стандарт ролей и процедур доступа. В платформенном подходе, включая проекты на базе решений СТАБУР, проще удерживать консистентную RBAC-модель между линиями: одинаковые роли, одинаковые правила временного повышения и единый аудит.
Заключение
RBAC в АСУ ТП - это не “ограничение ради ограничения”, а способ сделать эксплуатацию прозрачной и устойчивой. Как только исчезают общие пароли и появляется персональная ответственность за действия, снижается и вероятность ошибок, и стоимость любого инцидента.
FAQ
Можно ли оставить один общий логин “на всякий случай”?
Лучше нет. Для аварийных сценариев должна быть отдельная break-glass процедура, а не постоянный обход RBAC.
Что важнее: роли или журналирование?
Они работают только вместе. Роли задают границы, журналирование подтверждает исполнение.
Нужно ли оператору два аккаунта?
Обычно достаточно одного личного, если разграничение действий сделано по роли.
Как часто пересматривать права?
Минимум раз в квартал и после кадровых/организационных изменений.
Что делать с устаревшими сервисными учетками?
Инвентаризировать, убрать неиспользуемые, оставшиеся ограничить по минимуму прав и ротации секретов.