Безопасность шлюза оборудования и КИИ

Страница для службы информационной безопасности и инженеров АСУ ТП. Коротко: шлюз стоит внутри сети объекта, только читает оборудование и сам ходит в облако исходящим HTTPS на 443. Входящих соединений из интернета он не принимает.

Сетевые соединения

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

Выход в облако идёт через прокси, если он есть: явный в файле настроек или прокси машины (переменные окружения, на Windows ещё WinHTTP, PAC и WPAD). К оборудованию шлюз ходит напрямую. OPC DA на другой машине работает через DCOM: TCP 135 и динамический диапазон портов. Рекомендуемое место шлюза для OPC DA: та же машина, что сервер OPC DA, тогда DCOM не нужен.

Только чтение

В этой сборке шлюза нет записи в оборудование вообще: у драйверов нет ни записи значений, ни вызова методов. У OPC UA сессия шлюза умеет читать, подписываться и обновлять список аварий, и больше ничего. Выключателя записи в настройках нет, потому что записывать нечем.

Что задаёт объект, а не облако

• Список разрешённых адресов (equipment_hosts): подключение к адресу вне списка не запускается. Облако список расширить не может.
• Обновления (auto_update = false): выключают автообновление, и облако включить его обратно не может.
• Прокси и доверие сертификатам OPC UA: шлюз не доверяет неизвестному сертификату сервера, пока его не положили в список доверенных на объекте.

Как это настроить: файл настроек шлюза.

Ключ шлюза

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

Запуск и обновления

• Windows: служба от LocalSystem с автозапуском. Папку настроек в %ProgramData% шлюз закрывает правами системы и администраторов, чтобы подброшенный файл настроек не поменял прокси или обновления службы. Пакет обновления проверяется по подписи, и если новая версия не вышла на связь, служба возвращается на прежнюю.
• Linux, systemd: отдельный системный пользователь, без повышения прав, файловая система только на чтение, кроме каталога данных.
• Linux, контейнер: процесс внутри работает не от root. Сам себя шлюз на Linux не обновляет, новую версию ставит оператор.

Для источников, у которых известна уязвимость версии, строка подключения показывает «Уязвимость версии источника: …» с номером CVE.

Обрыв связи

Пока связи с облаком нет, шлюз продолжает читать оборудование и копит данные на своём диске. Когда связь вернулась, он отправляет накопленное, а повтор той же пачки не создаёт дублей. Потолок места задаёт объект (buffer_max_mb). Когда место кончается, вытесняются самые старые данные, и экран показывает, сколько отсчётов вытеснено: дыра в истории видна числом. OPC UA после обрыва связи с сервером дочитывает пропущенное из истории сервера, если сервер её хранит.

КИИ

Вопрос задаётся только тому, кто сам отметил объект как «Объект КИИ» при добавлении или в «Категория объекта». Обычный объект ничего не заполняет. Категорию значимости присваивает комиссия владельца объекта, облако её не выводит.

Почему значимый объект закрыт: приказ ФСТЭК № 239 не допускает на нём удалённого обновления ПО теми, кто не работник владельца объекта, и передачи технологической информации разработчику без его контроля. Шлюз держит исходящий канал в облако и обновляется по команде облака, поэтому такие объекты подключаются только в отдельном контуре: всё в РФ, обновления ставит сам владелец. Пока его нет, объект закрыт. ПАЗ/SIS протоколом не отличить от остальных (те же Modbus и OPC UA), поэтому отвечает владелец объекта.

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

Памятка для службы ИБ

• Входящих правил не нужно. Разрешите исходящий HTTPS на 443 с сервера шлюза к ingest.samreshuuu.ru, а для Windows с автообновлением ещё к хранилищу выпусков.
• Поставьте шлюз в DMZ или на сервер SCADA и ограничьте его доступ в сеть цеха портами нужных протоколов.
• Запишите в equipment_hosts адреса и сети, которые шлюзу можно читать.
• Решите, ставятся ли обновления сами. Если нет, auto_update = false, и обновления ставит оператор.
• Для OPC UA используйте защищённые конечные точки и положите сертификат сервера в список доверенных шлюза.
• Отметьте объект КИИ и его категорию до назначения подключений.
• Данные организации выгружаются архивом в любой момент, без секретов шлюза и учётных данных подключений. Общие правила хранения и доступа: безопасность.