Блог

Когда пароля недостаточно: Многофакторная аутентификация в российских реалиях АСУ ТП и требованиях КИИ

Долгое время безопасность отечественных промышленных систем строилась на базе двух «китов»: физической изоляции технологического сегмента и безусловного доверия внутри периметра. Считалось, что если злоумышленник не может физически подойти к шкафу автоматики, то и угроз нет. Однако цифровая трансформация и массовый переход на удаленное сервисное обслуживание, ускоренный кадровым голодом, сделали «воздушный зазор» фикцией. Сегодня периметр завода проницаем, а компрометация учетных записей стала одним из самых популярных векторов атак. В этих условиях полагаться только на пароли – значит оставлять двери открытыми.
Внедрение многофакторной аутентификации (MFA) в технологическом сегменте становится неизбежным шагом, который диктуется не только здравым смыслом, но и требованиями регуляторов, в частности 187-ФЗ о безопасности критической информационной инфраструктуры (КИИ). Однако механический перенос офисных практик в цех невозможен. Промышленная среда диктует свои жесткие условия, где приоритет доступности системы стоит выше конфиденциальности, а использование облачных сервисов зарубежных вендоров недопустимо.

Фундаментальный конфликт безопасности и производства

Главная сложность внедрения MFA на производстве кроется в конфликте между требованиями информационной безопасности (ИБ) и непрерывностью технологического процесса. В корпоративной сети задержка входа в систему на минуту – это мелкая неприятность. В диспетчерской, когда необходимо срочно локализовать аварию или изменить уставку защиты, любая заминка с вводом кодов или поиском токена может привести к физическому ущербу.
Ситуацию усложняет исторически сложившаяся практика использования коллективных учетных записей. На многих российских предприятиях под логином «Оператор» работают разные люди в разные смены. Это делает персонализированную аутентификацию невозможной без кардинального пересмотра внутренних регламентов. Кроме того, значительная часть парка промышленных ПК все еще функционирует на устаревших версиях Windows или специализированных ОС, которые попросту не умеют работать с современными протоколами аутентификации.
Отдельно стоит вопрос импортозамещения и санкционных рисков. Использование популярных на Западе облачных решений вроде Microsoft Authenticator или Google Auth в российском промышленном сегменте сейчас неприемлемо. Это создает зависимость от зарубежных облаков, которые могут быть отключены в любой момент, и нарушает требования по локализации данных. Поэтому отечественная промышленность ориентируется на On-premise решения (развернутые локально на серверах предприятия) и аппаратные токены российского производства.

Эшелонированная защита: от удаленки до контроллера

Поскольку внедрить усиленную аутентификацию сразу на всех узлах АСУ ТП технически сложно, стратегически верно выстраивать защиту эшелонами, начиная с самых уязвимых мест. «Нулевым» рубежом обороны является защита удаленного доступа. Большинство инцидентов с вирусами-шифровальщиками начинается именно через скомпрометированные VPN-соединения или RDP-сессии подрядчиков.
Для защиты этого периметра в России активно применяются отечественные MFA-платформы (например, решения от компаний MultiFactor, Индид или Алладин Р.Д.), которые позволяют развернуть сервер аутентификации внутри закрытого контура предприятия. Инженер или наладчик, подключающийся извне, обязан подтвердить свою личность вторым фактором, но сам процесс генерации кодов должен происходить автономно, без обращения к зарубежным серверам.
Следующим критическим уровнем являются инженерные станции и АРМ администраторов АСУ ТП. Это «мозговой центр» производства, откуда производится перепрограммирование ПЛК. Здесь стандартом становится использование аппаратных средств защиты, таких как токены Rutoken или JaCarta. Инженер физически подключает токен к рабочей станции и вводит PIN-код. Извлечение токена автоматически блокирует сессию, что гарантирует неотказуемость действий: мы точно знаем, чья цифровая подпись стоит под изменениями в логике работы контроллера.

Специфика «грязной зоны» и HMI

Самым сложным участком для внедрения MFA остаются рабочие места операторов (HMI/SCADA). В условиях цеха, где персонал часто работает в защитных перчатках, а экраны могут быть загрязнены, ввод сложных паролей или использование сканеров отпечатка пальца затруднительны. Использование личных смартфонов для получения одноразовых кодов также часто невозможно из-за запрета на пронос мобильных устройств в категорированные или взрывоопасные помещения.
Наиболее органичным решением для уровня операторов является использование бесконтактных идентификаторов. Практически на каждом заводе уже внедрена СКУД, и у сотрудников есть пропуски (RFID/NFC карты). Интеграция считывателей карт в клавиатуры или панели оператора позволяет реализовать быстрый и удобный вход. Оператор прикладывает карту (фактор владения) и вводит короткий PIN-код (фактор знания).
Для критически важных операций, таких как останов оборудования, изменение рецептуры или снятие блокировок, целесообразно настраивать сценарии повторной аутентификации. Даже если сессия уже открыта, система требует повторно «предъявить» права доступа (например, приложить карту мастера смены) непосредственно перед выполнением опасного действия. Это реализует принцип «подтверждения присутствия» в момент ответственности.

Режим аварийного доступа и требования регуляторов

Внедряя любые средства защиты, нельзя забывать о сценариях отказа. Что произойдет, если сервер аутентификации выйдет из строя или сгорит при пожаре? Технологический процесс не должен остановиться. Для таких случаев разрабатываются регламенты аварийного доступа, известные как «Break-glass». В сейфе начальника смены или руководителя службы ИБ хранится физический конверт с паролем локального администратора, который позволяет обойти систему MFA в экстренной ситуации. Каждое вскрытие такого конверта фиксируется и расследуется как инцидент, но это гарантирует, что безопасность не станет причиной технологической катастрофы.
Внедрение многофакторной аутентификации в российских реалиях – это сложный интеграционный проект. Он требует отказа от «зоопарка» разрозненных решений в пользу единых отечественных платформ, сертифицированных ФСТЭК. Это переход от модели «слепого доверия» внутри периметра к концепции нулевого доверия, где каждый субъект доступа, будь то человек или устройство, должен однозначно подтвердить свою легитимность, не создавая при этом помех для основного производства.