Обеспечение конфиденциальности данных в системах автоматизации

Урок 3 · COURSE-16: Основы Интернета Вещей и практическое применение · theory

COURSE-16-M04-L04 — Обеспечение конфиденциальности данных в системах автоматизации

Введение в конфиденциальность данных на платформе HI

Конфиденциальность данных — это не абстрактное понятие, а ключевой инженерный принцип, обеспечивающий защиту информации, генерируемой и обрабатываемой системой автоматизации. В контексте платформы HI, это право владельца объекта (дома, офиса) контролировать, кто имеет доступ к данным с датчиков движения, герконов, камер, счётчиков и кто может управлять исполнительными устройствами — реле, клапанами, приводами.

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

Основные угрозы конфиденциальности в экосистеме HI

Угрозы для систем на базе контроллера HI конкретны и требуют превентивных мер на этапе проектирования и внедрения.

Несанкционированный доступ к контроллеру:

* Вектор: Подключение к веб-интерфейсу Node-RED со стандартным паролем или без него. Получение доступа к контроллеру по SSH с использованием слабых паролей.

* Последствия: Полный контроль над объектом — возможность просматривать данные с датчиков, управлять освещением, розетками, климатом, а также изменять или удалять сценарии автоматизации.

Перехват данных в локальной сети:

* Вектор: Прослушивание (сниффинг) незащищенного Wi-Fi трафика. Если протокол MQTT используется без шифрования (TLS), все команды и данные телеметрии передаются в открытом виде.

* Последствия: Злоумышленник может узнать расписание присутствия людей в доме, текущее энергопотребление, уставки климатических систем. Он также может отправлять поддельные команды, например, на открытие замка, управляемого через реле.

Утечка данных через уязвимости в сценариях:

* Вектор: Некорректно написанный сценарий в Node-RED, который, например, логирует в общедоступный MQTT-топик или в незащищенную базу данных MySQL чувствительную информацию (коды доступа, персональные данные).

* Последствия: Неконтролируемое распространение конфиденциальной информации, которое сложно отследить и устранить.

Методы обеспечения конфиденциальности на контроллере HI

Для защиты данных на объекте необходимо применять комплексный подход, основанный на трех фундаментальных методах.

1. Шифрование данных

Шифрование — это процесс преобразования данных в нечитаемый формат, доступный только при наличии ключа. Это базовый уровень защиты.

Шифрование при передаче (Data in Transit):

* Задача: Защитить данные, передаваемые по сети.

* Решение на платформе HI:

1. HTTPS для Node-RED: Включение SSL/TLS для веб-интерфейса редактора. Это защищает логику сценариев и учетные данные от перехвата.

2. MQTT с TLS (MQTTS): Настройка встроенного MQTT-брокера Mosquitto для работы через защищенный порт 8883 с использованием TLS-сертификатов. Все узлы `mqtt in` и `mqtt out` в Node-RED должны быть настроены на использование TLS.

💡 Совет: Используйте самоподписанные сертификаты для локальных сетей. Этого достаточно для защиты от перехвата внутри объекта и не требует затрат.

Шифрование при хранении (Data at Rest):

* Задача: Защитить данные, хранящиеся на контроллере (в базе MySQL или в файлах).

* Решение на платформе HI: Применение шифрования на уровне приложения. Перед записью чувствительных данных (например, архива событий безопасности) в базу MySQL, их следует зашифровать внутри узла `Function` в Node-RED с помощью стандартных криптографических библиотек.

2. Анонимизация и псевдонимизация данных

Не всегда требуется хранить и передавать исходные, персонально идентифицируемые данные.

Анонимизация: Удаление всей информации, позволяющей идентифицировать субъекта.

* Пример: Вместо хранения лога `{"user": "Иван Петров", "action": "открыл дверь", "time": "..."}` система хранит агрегированные данные: `{"door_opens_count": 25}`.

Псевдонимизация: Замена идентификаторов на псевдонимы.

* Пример: Вместо `Иван Петров` используется `user_A1B2`. Это позволяет анализировать поведение конкретного пользователя, не раскрывая его личности. Практическая реализация в Node-RED (FLOW-PRIVACY-ANON-001):

Предположим, датчик движения в кабинете отправляет сообщения. Мы хотим собирать статистику активности, но не хотим логировать точное время каждого срабатывания.

// ASCII-схема потока
[mqtt in: "raw/office/motion"] -> [Function: Anonymize] -> [mqtt out: "stats/office/activity"]

Код для узла `Function: Anonymize`:

// Контракт входящего сообщения: msg.payload = {"value": true, "source": "motion-sensor-office", "ts": 1678886400000}
// Цель: вместо точного времени, считать количество срабатываний за час.

// Получаем текущий час как ключ для агрегации
const now = new Date();
const hourKey = `activity_${now.getFullYear()}-${now.getMonth()+1}-${now.getDate()}_${now.getHours()}`;

// Получаем текущий счетчик из контекста потока (сохраняется между вызовами)
let activityCount = flow.get(hourKey) || 0;
activityCount++;

// Сохраняем обновленное значение
flow.set(hourKey, activityCount);

// Формируем новое, анонимизированное сообщение
msg.payload = {
    hourly_triggers: activityCount,
    zone: "office",
    period_start_ts: new Date(now.getFullYear(), now.getMonth(), now.getDate(), now.getHours()).getTime()
};
msg.topic = "telemetry/stats/office/activity_hourly";

node.status({fill:"green", shape:"dot", text: `Count for hour ${now.getHours()}: ${activityCount}`});

return msg;

3. Контроль доступа (Access Control)

Контроль доступа гарантирует, что только авторизованные пользователи или системы могут читать данные и выполнять команды.

Уровень контроллера:

* SSH: Отключите вход по паролю, используйте только SSH-ключи. Установите `fail2ban` для блокировки попыток подбора пароля.

* Node-RED: В файле `settings.js` обязательно настройте секцию `adminAuth` для защиты редактора паролем.

Уровень MQTT:

* Аутентификация: Настройте в `mosquitto.conf` файл с логинами и паролями.

* Авторизация (ACL - Access Control List): Создайте файл ACL, который определяет, какой пользователь в какие топики может писать (write) и из каких читать (read).

Пример файла ACL для `mosquitto`:

# /etc/mosquitto/acl.conf

# Администратор (admin_user) может делать всё
user admin_user
topic #

# Пользователь "клиент" (client_user) может управлять светом и климатом в гостиной,
# но только читать данные с датчиков во всем доме.
user client_user
topic read telemetry/#
topic readwrite commands/living_room/#

# Датчики могут только публиковать данные в свои топики
user sensor_user
topic write telemetry/sensors/#

⚠️ Предупреждение: Без настройки ACL любой, кто подключится к MQTT-брокеру, сможет управлять всеми устройствами и читать все данные.

Регуляторные аспекты и этика

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

152-ФЗ "О персональных данных" (Россия): Если система собирает, хранит или обрабатывает данные, позволяющие идентифицировать физическое лицо (ФИО, номер телефона, биометрия, иногда даже IP-адрес), оператор такой системы (ваш клиент) несет ответственность за их защиту.
GDPR (Евросоюз): Если ваш клиент — гражданин ЕС, применяются еще более строгие правила.

📋 Чек-лист для инженера:

Выясните у клиента, будут ли в системе обрабатываться персональные данные.

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

Применяйте описанные выше технические меры (шифрование, контроль доступа) по умолчанию для всех проектов.

В договоре на внедрение системы зафиксируйте раздел об ответственности за защиту данных и разграничении зон ответственности между вами (интегратором) и клиентом (оператором).

Заключение

Обеспечение конфиденциальности — это не опция, а обязательная часть профессиональной работы инженера по автоматизации. Использование шифрования для каналов связи (HTTPS, MQTTS), строгий контроль доступа на уровне контроллера и сервисов (SSH-ключи, MQTT ACL), а также грамотное проектирование сценариев с учетом анонимизации данных, формируют надежный защитный контур. Платформа HI предоставляет все необходимые инструменты для реализации этих мер. Ваша задача — правильно и в полном объеме их применять.

---

Лабораторные работы

COURSE-16-M04-LAB07: Настройка защищенного канала связи (MQTTS)

Цель: Обеспечить шифрование трафика между MQTT-клиентами и брокером на контроллере HI.
Оборудование: Контроллер HI, ПК инженера.
Пошаговая инструкция:

1. Подключитесь к контроллеру по SSH.

2. Сгенерируйте самоподписанный TLS-сертификат и ключ с помощью `openssl`.

3. Сконфигурируйте брокер Mosquitto (`/etc/mosquitto/mosquitto.conf`) для прослушивания порта 8883 и укажите пути к файлам сертификата и ключа.

4. Перезапустите службу Mosquitto.

5. В Node-RED, в настройках узла `mqtt out`, создайте новую конфигурацию MQTT-брокера: укажите порт 8883, включите опцию "Enable secure (SSL/TLS) connection" и добавьте новую конфигурацию TLS, указав путь к файлу центра сертификации (CA).

6. Разверните поток и убедитесь, что узел `mqtt out` успешно подключился к брокеру (статус "connected").

Рубрика оценивания:

* (30%) Сертификаты сгенерированы и размещены в корректной директории.

* (40%) Конфигурация Mosquitto изменена для работы с TLS на порту 8883.

* (30%) Узел MQTT в Node-RED успешно подключается к брокеру по защищенному каналу.

COURSE-16-M04-LAB08: Внедрение ролевой модели доступа (MQTT ACL)

Цель: Разграничить права доступа к MQTT-топикам для разных пользователей.
Оборудование: Контроллер HI, ПК инженера с MQTT-клиентом (например, MQTT Explorer).
Пошаговая инструкция:

1. Создайте файл паролей для Mosquitto и добавьте двух пользователей: `manager` и `resident`.

2. Создайте файл ACL (`/etc/mosquitto/acl.conf`).

3. В файле ACL пропишите правила: `manager` имеет полный доступ (`topic #`), а `resident` может только публиковать в `telemetry/#` и подписываться на `commands/lights/#`.

4. В `mosquitto.conf` укажите пути к файлу паролей и файлу ACL. Перезапустите службу.

5. С помощью MQTT Explorer подключитесь поочередно под пользователем `resident` и `manager`.

6. Проверьте, что `resident` не может публиковать сообщения в топик `commands/security/set`, но может в `commands/lights/set`. Проверьте, что `manager` может делать всё.

Рубрика оценивания:

* (30%) Файлы паролей и ACL созданы и корректно сконфигурированы.

* (40%) Mosquitto использует оба файла для аутентификации и авторизации.

* (30%) Тесты с помощью MQTT-клиента подтверждают, что правила ACL работают корректно для обоих пользователей.

---

Тест для самопроверки

COURSE-16-M04-QUIZ

Какая основная угроза при использовании MQTT без TLS в открытой Wi-Fi сети?

* a) Перегрев контроллера

* b) Перехват и подмена команд и данных

* c) Быстрый износ EEPROM

* d) Сбой шины RS-485

В каком файле настраивается аутентификация для веб-интерфейса Node-RED?

* a) `/etc/mosquitto/mosquitto.conf`

* b) `~/.node-red/flows.json`

* c) `~/.node-red/settings.js`

* d) `/etc/ssh/sshd_config`

Что такое MQTT ACL?

* a) Протокол шифрования данных

* b) Список контроля доступа, определяющий права пользователей на топики

* c) Алгоритм сжатия MQTT-пакетов

* d) Стандарт для именования топиков

Какой инструмент на Debian рекомендуется использовать для защиты от подбора SSH-паролей?

* a) `openssl`

* b) `iptables`

* c) `cron`

* d) `fail2ban`

Что делает анонимизация данных?

* a) Шифрует данные с помощью ключа

* b) Удаляет из данных информацию, позволяющую идентифицировать личность

* c) Архивирует старые данные

* d) Проверяет целостность данных

Стандартный защищенный порт для MQTT (MQTTS) — это...

* a) 1883

* b) 8883

* c) 443

* d) 502

Зачем нужен файл паролей при настройке Mosquitto?

* a) Для шифрования трафика

* b) Для аутентификации клиентов (проверки "кто ты?")

* c) Для авторизации клиентов (проверки "что тебе можно?")

* d) Для хранения логов

При подключении экрана кабеля RS-485 для минимизации помех, его следует подключать:

* a) К клемме GND на обоих концах линии

* b) К клемме GND только со стороны контроллера

* c) К клемме +24V

* d) Не подключать вообще

Какой федеральный закон РФ регулирует обращение с персональными данными?

* a) 123-ФЗ "Технический регламент о требованиях пожарной безопасности"

* b) 152-ФЗ "О персональных данных"

* c) 184-ФЗ "О техническом регулировании"

* d) 261-ФЗ "Об энергосбережении"

В чем заключается метод "Контроль доступа"?

* a) В установке физических замков на электрощит

* b) В шифровании всех данных на диске

* c) В предоставлении доступа к данным и функциям строго на основе прав и ролей

* d) В регулярном обновлении программного обеспечения

---

Мини-runbook: "Если не работает"

Проблема: MQTT-клиент (или узел в Node-RED) не может подключиться к брокеру по MQTTS (порт 8883).

* Диагностика:

1. Проверьте, что служба `mosquitto` запущена: `systemctl status mosquitto`.

2. Проверьте, что порт 8883 прослушивается: `netstat -tuln | grep 8883`.

3. Проверьте лог Mosquitto на предмет ошибок, связанных с TLS: `journalctl -u mosquitto -f`. Частая ошибка — "Error: Problem with CA certs" или "Error: Unable to load server key file".

4. Убедитесь, что пути к файлам сертификата и ключа в `mosquitto.conf` верны, и у пользователя `mosquitto` есть права на их чтение.

5. Проверьте, что файрвол на контроллере не блокирует порт 8883.

Проблема: Пользователь не может подписаться на топик или опубликовать в него, хотя аутентификация проходит успешно.

* Диагностика:

1. Это классический симптом работы ACL. Внимательно проверьте правила в файле ACL (`acl.conf`).

2. Убедитесь, что для пользователя прописаны права (`read`, `write` или `readwrite`) именно на тот шаблон топика, к которому он обращается.

3. Помните, что правила применяются последовательно. Более специфичные правила должны идти раньше общих.

4. Проверьте, что в `mosquitto.conf` включена опция `allow_anonymous false` и указан путь к `acl_file`.