Приветствую всех, кто строит и защищает нашу промышленность! На связи снова «Изнанка автоматизации».
Давайте начнем с картины, которая знакома каждому, кто хоть раз заходил в операторную любого завода – от пищевого комбината до нефтепереработки. Полумрак, гудение серверов, ряды мониторов с мнемосхемами SCADA. И почти на каждом втором мониторе, в уголке, приклеен желтый стикер. А на нем ручкой старательно выведено: «Login: Operator, Pass: 123456».
Долгое время мы закрывали на это глаза. Безопасность отечественных промышленных систем строилась на двух «китах». Первым была физическая изоляция: технологический сегмент (сеть АСУ ТП) был физически отрезан от интернета и офисной сети. Вторым «китом» было безусловное доверие внутри периметра: считалось, что если злоумышленник не может физически подойти к шкафу автоматики или сесть за АРМ оператора, то и угрожать нам нечему.
Но мир изменился. Цифровая трансформация, о которой так много говорят, и суровая реальность кадрового голода сделали своё дело. Массовый переход на удаленное сервисное обслуживание привел к тому, что легендарный «воздушный зазор» (Air Gap) превратился в фикцию. Сегодня периметр завода проницаем: подрядчики подключаются через VPN, данные улетают в MES-системы, а инженеры настраивают контроллеры из дома.
Компрометация учетных записей стала одним из самых популярных векторов атак на заводы. В этих условиях полагаться только на пароли – значит оставлять двери открытыми настежь. Пришло время поговорить о многофакторной аутентификации (MFA) – неизбежном шаге, который диктуется не только здравым смыслом, но и жесткими требованиями регуляторов, в частности 187-ФЗ о безопасности критической информационной инфраструктуры (КИИ).
Но как внедрить это на живом производстве, не остановив его? Ведь завод – это не офис, и механический перенос IT-практик здесь невозможен. Давайте разбираться.
Фундаментальный конфликт: Безопасность против Непрерывности
Главная сложность внедрения MFA на производстве кроется в вечном конфликте между требованиями информационной безопасности (ИБ) и святая святых производства – непрерывностью технологического процесса.
В корпоративной офисной сети приоритеты расставлены так: Конфиденциальность – Целостность – Доступность. Если менеджер утром задержится на минуту при входе в почту, потому что ему не пришла SMS с кодом – это мелкая неприятность. Никто не умрет, компания не разорится.
В промышленной сети (OT) приоритеты перевернуты: Доступность – на первом месте. В диспетчерской, когда необходимо срочно локализовать аварию, сбросить давление или изменить уставку защиты, любая заминка смерти подобна. Если оператор будет судорожно искать токен или вспоминать код, это может привести к физическому ущербу оборудованию, экологической катастрофе или травмам персонала.
Ситуацию усложняют наши исторические реалии:
- Коллективные аккаунты. На многих российских предприятиях под одним логином «Оператор» работают разные люди в разные смены (утро/день/ночь). Это делает персонализированную аутентификацию невозможной без кардинального пересмотра внутренних регламентов и организационной структуры.
- Зоопарк «железа» и софта. Значительная часть парка промышленных ПК все еще функционирует на устаревших версиях Windows (XP, 7) или специализированных ОС реального времени. Эти системы попросту не умеют работать с современными протоколами аутентификации, которые привычны айтишникам.
Почему Google и Microsoft нам не друзья (в цеху)
Отдельно стоит больной вопрос импортозамещения и санкционных рисков. Если в офисе вы привыкли пользоваться Microsoft Authenticator или Google Auth, то забудьте об этом в промышленном сегменте.
Использование популярных западных облачных решений в российском контуре АСУ ТП (особенно на объектах КИИ) сейчас неприемлемо. Это создает критическую зависимость от зарубежных облаков, которые могут быть отключены или заблокированы в любой момент. Кроме того, это прямо нарушает требования регуляторов по локализации данных.
Поэтому отечественная промышленность жестко ориентируется на On-premise решения. Это значит, что сервер аутентификации должен быть развернут локально, внутри закрытого контура предприятия, на собственных серверах. А в качестве второго фактора используются аппаратные токены исключительно российского производства.
Стратегия защиты: Строим эшелоны
Поскольку внедрить усиленную аутентификацию сразу на всех узлах АСУ ТП – от полевого контроллера до SCADA-сервера – технически невероятно сложно и дорого, стратегически верно выстраивать защиту эшелонами, начиная с самых уязвимых мест.
Мы выделяем три главных рубежа обороны.
Рубеж №1: Удаленный доступ (Критически важно)
Это «нулевой» рубеж. Большинство громких инцидентов с вирусами-шифровальщиками последних лет начиналось именно так: хакеры крали пароль подрядчика или инженера и заходили через VPN или RDP.
Защита удаленного доступа должна быть реализована в первую очередь. Для этого в России активно применяются отечественные MFA-платформы (например, решения от компаний MultiFactor, Индид или Алладин Р.Д.). Эти системы позволяют развернуть сервер аутентификации внутри периметра завода.
Работает это так: инженер или наладчик, подключающийся из дома или из офиса вендора, вводит логин и пароль. Но соединение не устанавливается, пока он не подтвердит свою личность вторым фактором (например, через российское мобильное приложение или Telegram-бот, работающий через локальный шлюз). Важно, что сам процесс генерации и проверки кодов происходит автономно, без обращения к зарубежным серверам.
Рубеж №2: «Мозговой центр» (Инженеры и Админы)
Следующий критический уровень – это инженерные станции и АРМ администраторов АСУ ТП. Это те самые компьютеры, с которых производится перепрограммирование ПЛК, изменение логики работы конвейеров и настройка защит. Ущерб от несанкционированного доступа здесь максимален.
Здесь стандартом де-факто становится использование аппаратных средств защиты – USB-токенов, таких как Rutoken или JaCarta. Это работает надежно и просто:
- Инженер физически подключает токен (похожую на флешку) к рабочей станции.
- Вводит свой PIN-код.
- Система пускает его в среду разработки.
Самое главное преимущество: извлечение токена автоматически блокирует сессию. Отошел от компьютера – выдернул токен – доступ закрыт. Это гарантирует неотказуемость действий (Non-repudiation): мы точно знаем, чья цифровая подпись стоит под изменениями в коде контроллера, и никто не сможет сказать «это не я, это Петров сел за мой комп».
Рубеж №3: «Поле боя» (Операторы HMI/SCADA)
Это самый сложный участок для внедрения MFA. Представьте условия реального цеха: пыль, вибрация, грязь. Персонал часто работает в толстых защитных перчатках. В таких условиях требовать от оператора ввода сложных паролей или использования емкостных сканеров отпечатка пальца (которые не работают с грязными руками) – это издевательство.
Использование личных смартфонов для получения PUSH-уведомлений или кодов здесь также часто невозможно. Во многих цехах (особенно во взрывоопасных зонах или на режимных объектах) действует строгий запрет на пронос мобильных устройств.
Какое решение наиболее органично? Использовать то, что у оператора уже есть – бесконтактные идентификаторы. Практически на каждом заводе уже внедрена СКУД (Система Контроля и Управления Доступом), и у каждого сотрудника есть пропуск – RFID или NFC карта.
Интеграция считывателей карт в клавиатуры или прямо в панели оператора (например, в современные панельные контроллеры СТАБУР, которые часто имеют встроенные считыватели) позволяет реализовать быстрый и удобный вход. Сценарий выглядит так:
- Оператор подходит к пульту.
- Прикладывает карту к считывателю (Фактор владения).
- Вводит короткий PIN-код на экране (Фактор знания).
Это занимает секунды и не требует снимать перчатки.
Лайфхак для критических операций: Можно настроить систему так, чтобы для простого просмотра мнемосхем повторная аутентификация не требовалась. Но для критически важных операций – таких как останов оборудования, изменение рецептуры смеси или снятие программных блокировок – целесообразно настраивать сценарии повторной аутентификации. Даже если сессия уже открыта, система требует повторно «предъявить» права доступа (например, приложить карту мастера смены) непосредственно перед выполнением опасного действия. Это реализует принцип «подтверждения присутствия» в момент ответственности.
План «Б»: Режим «Разбить стекло»
Внедряя любые, даже самые надежные средства защиты, нельзя забывать о законе Мерфи. Что произойдет, если сервер аутентификации выйдет из строя? Если сгорит сетевая карта? Если начнется пожар, и нужно срочно остановить процесс, а система требует код, который не приходит?
Технологический процесс не должен остановиться из-за проблем с безопасностью. Для таких случаев разрабатываются специальные регламенты аварийного доступа, известные в мире как Break-glass («Разбить стекло»).
Как это выглядит на практике? В сейфе начальника смены или руководителя службы ИБ хранится опечатанный физический конверт. Внутри – сложный пароль локального администратора, который позволяет зайти в систему в обход любых токенов и серверов MFA. В экстренной ситуации конверт вскрывается. Да, каждое вскрытие такого конверта фиксируется и потом тщательно расследуется как инцидент ИБ. Но наличие такой возможности гарантирует, что безопасность не станет причиной технологической катастрофы.
Итог: От слепого доверия к Нулевому доверию
Внедрение многофакторной аутентификации в российских реалиях – это сложный интеграционный проект, а не просто установка софта. Он требует:
- Понимания специфики производства.
- Отказа от «зоопарка» разрозненных решений в пользу единых отечественных платформ, сертифицированных ФСТЭК.
- Железных нервов при общении с пользователями.
Это переход от устаревшей модели «слепого доверия» внутри периметра к современной концепции Zero Trust (Нулевое доверие). В этой концепции каждый субъект доступа – будь то человек, контроллер или скрипт – должен однозначно подтвердить свою легитимность, прежде чем получить доступ к ресурсам завода. И сделать это нужно так, чтобы не создавать помех для основного производства.
Коллеги, а как у вас на производстве обстоят дела с паролями? Все еще «123456» на желтом стикере, или уже внедрили токены? Делитесь болью и опытом в комментариях, это важно!
Автор: Дмитрий Михилев, инженер АСУ ТП
#двухфакторнаяаутентификация #промышленнаябезопасность #АСУТп #MFA #киберзащита #критическаяинформационнаяинфраструктура #цифроваятрансформация #импортозамещение #ZeroTrust #производство