Доступ и защищённое подключение

Два независимых уровня доступа

Учётная запись Studio определяет, кто может работать в среде разработки и какие проекты ему доступны. Внутренняя безопасность проекта определяет права внутри конкретной системы. Пароль Studio не заменяет пароль проекта.

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

Личная квота ограничивает число собственных проектов. Создание и импорт увеличивают число проектов пользователя; удаление освобождает место в пределах квоты. Передачу проекта другому владельцу выполняет администратор.

Настройка пользователя Studio

1. Войдите администратором Studio и откройте «Пользователи Studio».
2. Нажмите «＋ Добавить», задайте логин и отображаемое имя.
3. В блоке «Доступ и ограничения» включите нужные разрешения. Для разработчика без права загрузки на узлы оставьте создание проектов включённым, а «Разрешить заливку проектов на узлы» выключите.
4. При необходимости включите ограничение числа собственных проектов и задайте максимальное количество. После удаления проекта место в пределах лимита освобождается.
5. Задайте и повторите пароль. В раскрывающемся блоке «Доступ к чужим проектам» выберите проекты, которые пользователь должен видеть, и нажмите «Сохранить пользователя».

Пошаговая настройка пользователей и групп внутри проекта приведена в разделе «Пользователи и группы проекта».

Отключение общего входа в Studio

В studio.json поле studio_access_control_enabled по умолчанию включено. Если администратор устанавливает false, все проекты, создание, импорт, загрузка на узлы, управление пользователями и общие каталоги доступны без входа в Studio. Права и квоты Studio не применяются. Внутренние пароли и права проектов продолжают действовать. Проекты, созданные без входа, не имеют владельца Studio. Перед повторным включением контроля создайте администратора и назначьте доступ к этим проектам.

"studio_access_control_enabled": false

Измените это поле в существующем studio.json и перезапустите службу. При false вход, разрешения и квоты Studio не требуются. При true снова действуют ограничения учётных записей Studio.

Возврат к ограничению доступа

1. Убедитесь, что существует активный администратор Studio. Если его нет, создайте его на сервере командой /opt/SAMUTAG/Studio/current/venv/bin/python /opt/SAMUTAG/Studio/current/manage.py studiocreateadmin.
2. Установите studio_access_control_enabled в true и перезапустите samutag-studio.
3. Войдите администратором и откройте «Пользователи Studio» → «Владельцы проектов и передача».
4. Выберите проект с пометкой «без владельца» и нужного активного пользователя, нажмите «Передать проект». У получателя должно оставаться место в квоте.
5. Проверьте вход под получателем. Проект появится в его списке; для открытия потребуется прежний внутренний пароль проекта.

Назначение владельца не изменяет содержимое проекта и его пароли. Если нужно предоставить доступ без передачи владения, выберите проект в настройках пользователя Studio. После включения контроля снова действуют разрешения создания, импорта и загрузки на узлы, назначения проектов и квоты.

Онлайн-справка доступна без входа в Studio.

Пользователи проекта и операторские команды

В проекте настройте пользователей, группы и разрешения на просмотр, изменение и запись тэгов. Встроенные root и Anonymous имеют особое назначение: первый используется для административного доступа, второй — для анонимного режима.

Для тэга проверьте доступ на запись и требование повторного подтверждения паролем, если оно включено. На уровне I/O-сервера может быть запрещена запись в ПЛК. Эти ограничения дополняют друг друга: разрешение в графической кнопке не отменяет запрет сервера.

Проверьте права в Studio и на АРМ под операторской учётной записью. Чтобы изменения прав доступа вступили в силу на узлах, загрузите обновлённый проект.

Пример: права оператора насосной станции

Создадим пользователя Operator1 из группы Operators. Оператору будет доступен видеокадр OperatorScreen с температурой воды и уставкой. Он сможет изменять уставку после подтверждения паролем. Инженерный видеокадр Engineering останется доступным группе Engineers.

1. Создайте учётную запись и включите безопасность

1. Войдите в проект как root. На вкладке «Пользователи» создайте группы Operators и Engineers.
2. Создайте пользователя Operator1, задайте ему пароль и включите членство только в Operators. Оставьте пользователя включённым.
3. В настройках проекта включите «Использовать безопасность» и «Разрешить выбор пользователя при входе». В «Разрешение на просмотр» отметьте Operators; в «Разрешение на редактирование» оставьте только Engineers. Сохраните настройки.

Формы создания и настройки показаны в разделе «Пользователи и группы проекта». Разрешение просмотра проекта относится к работе в Studio. Доступ к отдельным экранам АРМ задаётся далее.

2. Разрешите рабочий видеокадр

1. Откройте OperatorScreen в редакторе видеокадров и нажмите «Свойства» в верхней панели.
2. В блоке «Безопасность» включите «Ограничить доступ» и отметьте Operators.
3. Для главного видеокадра включите «Запретить анонимный доступ», чтобы при открытии АРМ требовался вход.
4. Нажмите «Сохранить». Назначьте кадр нужному узлу АРМ и сделайте его главным для этого АРМ.

3. Закройте инженерный видеокадр

1. Откройте свойства Engineering.
2. Включите «Ограничить доступ». Отметьте только Engineers; Operators оставьте выключенным.
3. Сохраните кадр. Если он использует базовый видеокадр, проверьте также права базового кадра: оператор должен иметь доступ ко всей цепочке.

4. Покажите значения тэгов без разрешения записи

В текущей версии отдельного списка групп для чтения каждого тэга нет. Значения, выведенные на доступный видеокадр, доступны его пользователям. Чтобы разделить просмотр данных между группами, разместите их на разных видеокадрах и настройте доступ к этим кадрам.

1. Создайте в шаблоне Pump тэги Float Temperature («Температура воды») и Setpoint («Уставка температуры»), единицы измерения — °C. Создайте экземпляр Pump1.
2. В символе настройте «Вывод значения» для обоих тэгов и разместите символ Pump1 на OperatorScreen. Порядок привязки показан в примере создания графического символа.
3. Откройте редактор Temperature. В блоке «Безопасность» оставьте Operators выключенным в списке «Группы, которым разрешена запись». Для примера можно оставить выключенными все группы. Сохраните тэг.

5. Разрешите изменение уставки

1. Откройте редактор Setpoint. В основных свойствах разрешите чтение и запись.
2. В блоке «Безопасность» включите Operators и «Подтверждение паролем». Нажмите «Сохранить».
3. В редакторе символа добавьте к полю уставки анимацию ввода значения, привязанную к Setpoint. Анимация «Вывод значения» сама по себе только показывает данные.
4. Сохраните символ и видеокадр. Загрузите обновлённый проект на Runtime и АРМ.

Если блок безопасности унаследован и заблокирован, измените его в родительском шаблоне либо разрешите переопределение там. Для уставки, связанной с ПЛК, также проверьте разрешение записи в настройках I/O-сервера.

6. Проверьте работу под Operator1

1. Откройте адрес АРМ в отдельном окне браузера. Если ранее выполнен вход как root, сначала выйдите через объект авторизации на видеокадре.
2. Выберите Operator1, введите его пароль и нажмите «Войти».
3. Убедитесь, что OperatorScreen открылся и показывает оба значения. В учебном примере Temperature равен 65, Setpoint — 60.
4. Попробуйте открыть Engineering: кадр не должен открыться. Проверьте также прямую ссылку на него, если она сохранена.
5. Попробуйте изменить Temperature: изменение должно быть недоступно, значение должно остаться прежним.
6. Введите для Setpoint значение 62. Сначала отмените подтверждение: значение должно остаться 60. Повторите ввод и подтвердите своим паролем: значение должно стать 62.
7. Выйдите из АРМ. Для повторного доступа к главному кадру система должна снова запросить вход.

Если проверка не совпала с таблицей, проверьте группы Operator1, переключатель безопасности проекта, права кадра и его базы, настройки конкретного тэга и загрузку последних изменений на узлы. После обновления проекта войдите в АРМ заново.

Studio за Apache: отдельный HTTPS-домен

Gunicorn обслуживает Django-приложение Studio. Apache принимает HTTPS-подключения и пересылает их на локальный HTTP-порт Gunicorn. Для нескольких сайтов создайте отдельный VirtualHost с нужным ServerName; не меняйте общие настройки остальных доменов.

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

"listen_host": "127.0.0.1",
"listen_port": 8000,
"public_url": "https://studio.example.ru",
"allowed_hosts": ["studio.example.ru", "localhost", "127.0.0.1"],
"csrf_trusted_origins": ["https://studio.example.ru"]

Включите модули Apache от root:

a2enmod proxy proxy_http headers ssl

Пример HTTPS-хоста для уже выпущенного сертификата. Имена домена, пути сертификата и адрес службы Studio замените своими:

<VirtualHost *:443>
    ServerName studio.example.ru
    SSLEngine On
    SSLCertificateFile /etc/letsencrypt/live/studio.example.ru/fullchain.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/studio.example.ru/privkey.pem
    ProxyRequests Off
    ProxyPreserveHost On
    ProxyAddHeaders Off
    RequestHeader unset X-Forwarded-For
    RequestHeader set X-Forwarded-For "expr=%{REMOTE_ADDR}"
    ProxyTimeout 300
    RequestHeader unset X-Forwarded-SSL
    RequestHeader unset X-Forwarded-Protocol
    RequestHeader set X-Forwarded-Proto "https"
    ProxyPass / http://127.0.0.1:8000/ connectiontimeout=5 timeout=300
    ProxyPassReverse / http://127.0.0.1:8000/
    ErrorLog ${APACHE_LOG_DIR}/samutag-studio-error.log
    CustomLog ${APACHE_LOG_DIR}/samutag-studio-access.log combined
</VirtualHost>

Сохраните конфигурацию в отдельном файле sites-available, включите её и проверьте синтаксис. Если домен уже имеет VirtualHost, дополните существующий вместо создания второго с тем же именем.

a2ensite samutag-studio.conf
apache2ctl configtest
apache2ctl -S
systemctl reload apache2
systemctl restart samutag-studio

После сообщения Syntax OK примените конфигурацию Apache командой systemctl reload apache2. Studio размещается в корне домена. Файлы оформления, изображения и JavaScript по адресу /static/ передаёт сама служба Studio. Приведённая настройка Apache направляет эти запросы в Studio вместе с запросами страниц; отдельная настройка для /static/ не требуется. Ограничьте доступ к порту Gunicorn адресом прокси.

HTTPS для операторского АРМ

1. Подготовьте домен и сертификат

В примере оператор открывает https://hmi.example.ru/, а Apache и HMI работают на одном компьютере. Замените домен своим. Запись DNS должна указывать на адрес Apache, сертификат — быть выпущен для этого домена. Для внутреннего центра сертификации установите его корневой сертификат на операторские компьютеры.

HMI работает как самостоятельная служба: Gunicorn для неё не нужен. Apache передаёт запросы на операторский HTTP-порт 8080. Порты управления 8865 и диагностики 8866 в этот сайт не включаются. Все номера здесь приведены для настроек по умолчанию.

Команды ниже предназначены для Debian/Ubuntu и совместимых систем с apt. Если sudo отсутствует, выполните su - и запускайте административные команды без sudo. Если Apache уже обслуживает другие домены, добавьте отдельный виртуальный хост; существующие сайты отключать не нужно.

2. Установите Apache и включите модули

sudo apt update
sudo apt install apache2 curl
sudo a2enmod proxy proxy_http headers ssl
sudo systemctl enable --now apache2

3. Подготовьте операторский порт HMI

В существующем /opt/SAMUTAG/Server.HMI/hmi.json задайте следующие поля. Это фрагмент JSON: добавьте его в существующий объект с правильными запятыми, сохранив node_id, token и остальные настройки.

"operator_host": "127.0.0.1",
"operator_port": 8080,
"trusted_proxies": ["127.0.0.1"]

operator_host ограничивает только операторский сайт. Поле host для управления и диагностики оставьте с адресом, по которому Studio подключается к узлу. trusted_proxies позволяет HMI учитывать переданный Apache адрес клиента в журнале безопасности.

sudo systemctl restart samutag-hmi
sudo systemctl status samutag-hmi --no-pager
curl -sS -o /dev/null -w "HTTP %{http_code}\n" http://127.0.0.1:8080/

Проверку curl выполните на машине Apache. Если подключение не устанавливается, сначала проверьте службу и operator_port. Перед проверкой работы экрана загрузите на HMI проект с назначенными видеокадрами.

4. Разместите сертификат

Если сертификат уже настроен на Apache для этого домена, используйте его существующие пути. Иначе получите сертификат у вашего центра сертификации и разместите цепочку сертификатов и закрытый ключ. Например, для файлов, предварительно скопированных в /tmp:

sudo install -d -m 755 /etc/ssl/samutag-hmi
sudo install -m 644 /tmp/hmi-fullchain.pem /etc/ssl/samutag-hmi/fullchain.pem
sudo install -m 600 /tmp/hmi-private.key /etc/ssl/samutag-hmi/privkey.pem

fullchain.pem содержит сертификат сервера и промежуточные сертификаты, privkey.pem — соответствующий закрытый ключ. Эти команды копируют готовые файлы, а не выпускают сертификат. Для уже настроенного Let’s Encrypt можно использовать /etc/letsencrypt/live/hmi.example.ru/fullchain.pem и privkey.pem напрямую. Продление сертификата настройте средствами выбранного центра сертификации; после замены файлов примените конфигурацию Apache.

5. Создайте конфигурацию сайта

Создайте /etc/apache2/sites-available/samutag-hmi.conf со следующим содержимым. Если VirtualHost для этого домена уже существует, внесите настройки в него вместо создания второго с тем же ServerName.

<VirtualHost *:80>
    ServerName hmi.example.ru
    Redirect permanent / https://hmi.example.ru/
</VirtualHost>

<VirtualHost *:443>
    ServerName hmi.example.ru
    SSLEngine On
    SSLCertificateFile /etc/ssl/samutag-hmi/fullchain.pem
    SSLCertificateKeyFile /etc/ssl/samutag-hmi/privkey.pem

    ProxyRequests Off
    ProxyPreserveHost On
    ProxyAddHeaders Off
    RequestHeader unset X-Forwarded-For
    RequestHeader set X-Forwarded-For "expr=%{REMOTE_ADDR}"
    RequestHeader set X-Forwarded-Proto "https"
    ProxyTimeout 300
    ProxyPass / http://127.0.0.1:8080/ connectiontimeout=5 timeout=300
    ProxyPassReverse / http://127.0.0.1:8080/

    ErrorLog ${APACHE_LOG_DIR}/samutag-hmi-error.log
    CustomLog ${APACHE_LOG_DIR}/samutag-hmi-access.log combined
</VirtualHost>

Блок порта 80 перенаправляет HTTP на HTTPS; если HTTP не используется, его можно не добавлять. Для проверки сертификата методом HTTP-01 сохраните правила вашего клиента продления. Модуль ssl в стандартной конфигурации Debian/Ubuntu добавляет прослушивание 443; при собственной конфигурации проверьте наличие Listen 443, не дублируя его.

Для потока значений и страниц журналов исключите сжатие и внешнее кеширование. Добавьте в VirtualHost:

<LocationMatch "^/api/v1/(subscriptions/|frames/[^/]+/alarms/)">
    SetEnv no-gzip 1
    SetEnv no-brotli 1
    Header always set Cache-Control "no-store, no-transform"
</LocationMatch>

HMI отправляет данные порциями по мере получения. Служебные сообщения поддерживают соединение между изменениями значений. Оставьте таймаут ProxyPass равным 300 секундам. После изменения проверьте конфигурацию и перезагрузите Apache приведёнными ниже командами. Настройка WebSocket не требуется.

ProxyPass передаёт страницы и запросы данных на HMI, ProxyPassReverse корректирует адреса перенаправлений. Apache формирует X-Forwarded-For из фактического адреса клиента. Пример рассчитан на прямое подключение операторов к Apache; если перед ним есть ещё один прокси, настройте доверенную цепочку отдельно.

6. Проверьте и примените конфигурацию

sudo a2ensite samutag-hmi.conf
sudo apache2ctl configtest
sudo apache2ctl -S

Продолжайте только после Syntax OK. В выводе apache2ctl -S проверьте, что домен hmi.example.ru относится к нужному файлу, а другие домены сохранили свои виртуальные хосты.

sudo systemctl reload apache2
curl -sS -o /dev/null -w "HTTP %{http_code}\n" https://hmi.example.ru/

Проверка HTTPS выполняется без отключения проверки сертификата. Для внутреннего центра сертификации добавьте его доверенный корневой сертификат либо укажите curl --cacert /путь/ca.crt. Если DNS ещё не обновлён, с машины Apache можно проверить домен так:

curl --resolve hmi.example.ru:443:127.0.0.1 -sS -o /dev/null -w "HTTP %{http_code}\n" https://hmi.example.ru/

7. Если Apache и HMI находятся на разных компьютерах

Например, Apache имеет адрес 192.168.10.5, HMI — 192.168.10.20. В обеих директивах ProxyPass замените 127.0.0.1:8080 на 192.168.10.20:8080. На компьютере HMI измените фрагмент hmi.json:

"operator_host": "192.168.10.20",
"operator_port": 8080,
"trusted_proxies": ["192.168.10.5"]

Перезапустите samutag-hmi и проверьте с компьютера Apache адрес http://192.168.10.20:8080/. Разрешите подключение к этому порту только от Apache. HTTPS в этой схеме защищает соединение браузера с Apache; участок Apache — HMI использует HTTP и должен проходить по доверенной сети или защищённому туннелю.

Для локального Apache внешний доступ к 8080 не требуется. Доступ к 443 разрешите операторским компьютерам, а к управляющим портам — только компьютерам обслуживания. Настройка UFW приведена в разделе «Журнал безопасности и fail2ban».

8. Проверьте работу оператора

Откройте https://hmi.example.ru/, войдите под операторской учётной записью и проверьте загрузку главного видеокадра, значения, тренды, аварии и всплывающие символы. Разрешённую запись проверьте на тестовом тэге. Затем проверьте восстановление связи после краткого разрыва на тестовом стенде.

Адрес отдельного кадра имеет вид https://hmi.example.ru/#UUID-кадра. Часть после # обрабатывается браузером: отдельных правил Apache для каждого кадра не требуется. Размещайте операторский сайт в корне отдельного домена, например hmi.example.ru, а Studio — на другом домене.

Если сайт не открылся

Ошибка сертификата: проверьте имя домена, срок действия, цепочку и доверие к центру сертификации. Ошибка 502 или 503: проверьте запуск HMI, адрес в ProxyPass и доступ Apache к operator_port. Открывается другой сайт: проверьте DNS, ServerName и apache2ctl -S. Страница открылась, но данных нет: проверьте загрузку проекта и связь HMI с Runtime в журнале узла.

sudo tail -n 100 /var/log/apache2/samutag-hmi-error.log
sudo journalctl -u apache2 -n 100 --no-pager
sudo journalctl -u samutag-hmi -n 100 --no-pager

Для проверки журнала безопасности выполните один контрольный неудачный вход и убедитесь, что записан адрес операторского компьютера, а не Apache. Порядок подключения fail2ban приведён ниже в руководстве и в каталоге fail2ban дистрибутива.

Описание директив: проксирование Apache и настройка TLS.

Журнал безопасности и fail2ban

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

Studio и HMI ведут отдельные журналы попыток входа. В их локальных JSON задаются security_log_path и trusted_proxies. Доверенный прокси нужен для корректного определения реального адреса клиента: без этого в журнал может записываться адрес Apache вместо адресов операторских компьютеров.

В trusted_proxies укажите адрес своего прокси. Настройте на прокси перезапись заголовка X-Forwarded-For фактическим адресом клиента, как в примере VirtualHost выше. Сначала выполните контрольный неудачный вход и убедитесь, что журнал содержит реальный адрес клиента.

Готовые фильтры, отключённые правила блокировки (jail) и инструкция находятся в каталоге fail2ban. После установки откройте /opt/SAMUTAG/Studio/fail2ban и /opt/SAMUTAG/Server.HMI/fail2ban. Следуйте инструкции именно своей версии: она содержит имена фильтров, logpath и проверочные команды.

Если Apache расположен на той же машине и непосредственно принимает подключения клиентов, добавьте в существующий JSON приложения следующий фрагмент. Для HMI измените путь журнала на его реальный storage_dir:

"trusted_proxies": ["127.0.0.1", "::1"],
"security_log_path": "/opt/SAMUTAG/Studio/logs/studio-security.log"

При внешнем балансировщике или CDN сначала согласуйте цепочку доверенных адресов. Пример VirtualHost выше предназначен для Apache, который видит клиента непосредственно.

В системах с пакетным менеджером apt выполните команды от root. Если файлы конфигурации уже существуют, сначала сравните их и сохраните собственные настройки:

apt-get install fail2ban logrotate
cd /opt/SAMUTAG/Studio/fail2ban
cp samutag-studio.conf samutag-hmi.conf /etc/fail2ban/filter.d/
cp samutag.local /etc/fail2ban/jail.d/samutag.local

В jail-файле проверьте logpath, port, ignoreip и действие блокировки, подходящее вашему firewall. Установите enabled = true для установленных компонентов. Для доступа через Apache используются HTTP/HTTPS-порты; управляющие порты узлов сюда не добавляют. Начальные примеры предусматривают пять отказов за десять минут и блокировку на тридцать минут.

fail2ban-regex /opt/SAMUTAG/Studio/logs/studio-security.log /etc/fail2ban/filter.d/samutag-studio.conf
fail2ban-client -t
systemctl restart fail2ban
fail2ban-client status samutag-studio

Fail2ban должен работать там, где firewall видит адрес клиента, обычно на машине Apache. На общем IP блокировка портов 80/443 затронет все домены, а не один VirtualHost. Протестируйте блокировку с отдельного адреса, сохранив административный доступ.

Установщик SAMUTAG не меняет firewall и не включает блокировки автоматически. Администратор подключает fail2ban после проверки фильтра, путей журналов и списка исключений. Ошибка определения IP может заблокировать общий прокси вместо нарушителя.

UFW: какие подключения разрешать

UFW ограничивает сетевой доступ к службам, а fail2ban временно блокирует адреса после неудачных попыток входа. Настройте UFW на каждом сервере с учётом установленных компонентов. Правило входящего доступа создаётся на машине, которая принимает соединение.

В таблице и примерах команд указаны порты по умолчанию. Порты Runtime, Studio, HMI, Historian и других служб можно изменить в их конфигурации. При настройке UFW подставьте фактические порты вашей установки.

Все перечисленные соединения используют TCP.

При опросе ПЛК Runtime выступает клиентом: он сам подключается к Modbus- или OPC UA-серверу оборудования. Это исходящее соединение; открывать входящие 502 или 4840 на Runtime только ради опроса не нужно. Для Modbus RTU по локальному последовательному порту сетевого правила нет. Для шлюзов и Modbus OVER TCP используется адрес и порт самого устройства.

Подготовка и сохранение административного доступа

Ниже команды выполняются от root. При наличии sudo можно запускать их с этим префиксом; если sudo отсутствует, сначала войдите через su -. На Debian и совместимых системах установите пакет и проверьте действующие правила:

apt-get install ufw
ufw status verbose
ufw status numbered
ss -lntp

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

До включения UFW разрешите свой административный адрес и фактический порт SSH. Сохраните текущую SSH-сессию и доступ к консоли сервера: применение правил может прервать соединение. После включения проверьте вход второй SSH-сессией.

Для примеров ниже приняты адреса: Studio — 192.168.10.10, Runtime — 192.168.10.20, резервный Runtime — 192.168.10.21, Historian — 192.168.10.30, HMI — 192.168.10.40, административный компьютер — 192.168.50.10, операторская сеть — 192.168.60.0/24. Замените их своими адресами; между сетями должна быть настроена маршрутизация.

На каждом новом сервере сначала добавьте разрешение SSH, затем задайте политику по умолчанию. На действующем сервере сначала проверьте совместимость этой политики с его остальными службами:

ufw allow proto tcp from 192.168.50.10 to any port 22
ufw default deny incoming
ufw default allow outgoing

В этом примере исходящие соединения разрешены, а ответы на установленные соединения обрабатываются штатными правилами UFW. Если организация ограничивает исходящий трафик, дополнительно согласуйте доступ к узлам, ПЛК, DNS, синхронизации времени и обновлениям. Для IPv6 проверьте IPV6=yes в /etc/default/ufw и добавьте разрешения для используемых IPv6-адресов: правила с конкретным IPv4-источником их не заменяют.

Studio и операторский сайт

На сервере Apache, обслуживающем Studio, разрешите HTTPS разработчикам. В примере доступ имеет административный компьютер:

ufw allow proto tcp from 192.168.50.10 to any port 443

На Apache, обслуживающем HMI, разрешите HTTPS операторской сети:

ufw allow proto tcp from 192.168.60.0/24 to any port 443

Если оба сайта находятся на одном сервере, примените оба правила. UFW различает адреса и порты, но не домены внутри одного HTTPS-порта: разделение доступа к виртуальным хостам настраивается в Apache и приложениях.

Порт 80 добавьте отдельно, если используется HTTP-перенаправление или проверка сертификата. Если сайт намеренно публикуется для любых адресов, вместо ограничения по источнику можно использовать ufw allow 443/tcp; для общедоступного HTTP — ufw allow 80/tcp.

При локальном Apache Studio должна слушать 127.0.0.1:8000; правило внешнего доступа к 8000 не добавляется. Аналогично не открывайте операторский 8080 наружу при локальном проксировании HMI. Для HMI задайте operator_host равным 127.0.0.1, чтобы ограничить только операторский порт. Поле host для управления и диагностики оставьте доступным Studio; разрешите эти подключения только с доверенных адресов.

При отдельном прокси разрешите внутренний порт только с адреса этого прокси. Например, на сервере Studio, если Apache имеет адрес 192.168.10.5:

ufw allow proto tcp from 192.168.10.5 to any port 8000

Для прямого доступа без Apache используйте только нужный вариант: первое правило — на Studio, второе — на HMI. Это HTTP-подключения; сами правила UFW не добавляют шифрование.

ufw allow proto tcp from 192.168.50.10 to any port 8000
ufw allow proto tcp from 192.168.60.0/24 to any port 8080

Правила для обмена между узлами

На Runtime 192.168.10.20 разрешите управление со Studio и получение значений со стороны HMI:

ufw allow proto tcp from 192.168.10.10 to any port 8765,8766
ufw allow proto tcp from 192.168.10.40 to any port 8766

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

ufw allow proto tcp from 192.168.10.21 to any port 8767

На резервном Runtime повторите правила для Studio и HMI, а доступ к 8767 разрешите от основного сервера 192.168.10.20. При использовании арбитра на его машине разрешите обоим серверам порт арбитра. Для межсерверного обмена добавьте отдельные разрешения к диагностическим портам соответствующих Runtime-источников.

Если в проекте несколько резервных пар, повторите настройку для каждой пары с её адресами и портами. Разрешите доступ к порту резервирования только партнёру соответствующего узла. На каждом Runtime разрешите доступ нужным HMI, а на Historian — всем Runtime, передающим ему историю, включая резервные узлы. На разных компьютерах можно использовать одинаковые стандартные порты; на одном компьютере каждой службе нужны свободные порты.

На HMI 192.168.10.40 разрешите служебное подключение Studio. Операторский доступ настройте по предыдущему подразделу:

ufw allow proto tcp from 192.168.10.10 to any port 8865,8866

На Historian 192.168.10.30 разрешите подключения Studio, обоих Runtime и HMI. Правило резервного Runtime нужно только при его наличии:

ufw allow proto tcp from 192.168.10.10 to any port 8095
ufw allow proto tcp from 192.168.10.20 to any port 8095
ufw allow proto tcp from 192.168.10.21 to any port 8095
ufw allow proto tcp from 192.168.10.40 to any port 8095

На отдельном сервере PostgreSQL разрешите доступ только приложениям, использующим его базы. Если на нём размещены обе базы:

ufw allow proto tcp from 192.168.10.10 to any port 5432
ufw allow proto tcp from 192.168.10.30 to any port 5432

Эти правила не заменяют listen_addresses, pg_hba.conf и пароли PostgreSQL. Если база находится на той же машине, что и её приложение, используйте локальное соединение и не открывайте 5432 в сеть.

Когда несколько компонентов работают на одном компьютере, объедините только необходимые ему правила. Для соединений через loopback внешние разрешения не нужны. Номер порта в UFW должен совпадать с фактически настроенным узлом.

Включение и проверка

После добавления необходимых правил включите UFW и проверьте результат:

ufw logging low
ufw enable
ufw status verbose
ufw status numbered
ss -lntp

1. Откройте новую SSH-сессию с разрешённого компьютера.
2. Проверьте вход в Studio и HMI с соответствующих рабочих мест.
3. В Studio проверьте соединение с Runtime, Historian и АРМ, затем загрузку проекта и получение значений.
4. Проверьте передачу истории и чтение исторического тренда. При резервировании убедитесь, что оба сервера видят друг друга.
5. С компьютера вне разрешённой сети проверьте, что служебные порты недоступны.

При отказе связи проверьте, слушает ли служба нужный порт в ss. Затем сопоставьте адрес источника и порт назначения с правилами UFW. Сообщения блокировок можно найти в журнале ядра; при настроенном rsyslog они могут также записываться в /var/log/ufw.log.

journalctl -k --since "10 minutes ago" | grep 'UFW BLOCK'

Удалите лишнее разрешение командой ufw delete с теми же параметрами, с которыми оно создано. Старое общее разрешение, например на 8000 для любых адресов, необходимо убрать после проверки ограниченного правила: политика deny incoming не отменяет уже существующие разрешения.

Подключение fail2ban к UFW

Если для блокировки используется действие ufw, UFW должен быть включён. Обычный вариант banaction = ufw может блокировать адрес по всем портам, включая SSH; поле port в jail само по себе не ограничивает это действие. Для Apache можно задать отдельный профиль только с веб-портами.

Создайте на машине Apache файл /etc/ufw/applications.d/samutag-web:

[SAMUTAG-Web]
title=SAMUTAG web access
description=Studio and HMI through Apache
ports=80,443/tcp

Проверьте профиль:

ufw app info SAMUTAG-Web

В существующих секциях [samutag-studio] и [samutag-hmi] файла /etc/fail2ban/jail.d/samutag.local задайте действие для этого профиля. Остальные проверенные настройки фильтра и журнала сохраните; включите только установленные компоненты:

banaction = ufw[application=SAMUTAG-Web]

Профиль не открывает порты сам по себе: разрешающие правила добавляются отдельно. Для прямого HTTP-доступа измените профиль на фактические веб-порты, например 8000 и 8080. Управляющие порты Runtime и HMI в этот профиль не включают. Проверьте поддержку параметра application в установленном /etc/fail2ban/action.d/ufw.conf.

fail2ban-client -t
systemctl restart fail2ban
fail2ban-client status samutag-studio
fail2ban-client status samutag-hmi
ufw status numbered

Проверьте состояние включённых jail. С отдельного тестового адреса выполните неудачные входы и убедитесь, что блокировка появляется перед разрешающими правилами. Для снятия тестовой блокировки используйте fail2ban-client set samutag-studio unbanip АДРЕС либо имя jail HMI. При внешнем прокси блокировку нужно применять на стороне, которая видит реальный сетевой адрес клиента, а не только его значение в HTTP-заголовке.

Справочные материалы: синтаксис и порядок применения правил UFW, действие UFW в fail2ban. Состав доступных действий зависит от версии пакета в вашей системе.

Что хранить отдельно и кому выдавать доступ

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

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