Безопасность данных в IoT-сетях: что важно для поставщиков ресурсов

Что защищать: показания, доступ и непрерывность учета

Безопасность данных включает три задачи: сохранить конфиденциальность, исключить незаметное изменение информации и обеспечить ее доступность. В дистанционном учете они тесно связаны. Утечка раскрывает сведения о потреблении, подмена приводит к неверным расчетам, а длительное отсутствие показаний затрудняет контроль баланса ресурсов.

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

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

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

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

Злоумышленнику необязательно перехватывать радиосигнал. Точкой входа может оказаться учетная запись подрядчика, не обновленный сервер или интерфейс обмена данными с избыточными правами. Поэтому оценка безопасности только по характеристикам LoRaWAN или NB-IoT оставляет существенную часть системы без внимания.

Общая статистика показывает значимость этих рисков. В Verizon DBIR 2026 эксплуатация уязвимостей указана как начальный способ проникновения в 31% рассмотренных случаев нарушения конфиденциальности данных. Доля случаев с участием третьих сторон достигла 48%. Последний показатель охватывает различные зависимости от поставщиков и партнеров, а не только доступ подрядчиков к системе.

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

^{Безопасность данных: риски за пределами радиоканала}

LoRaWAN и NB-IoT: где проходят границы защиты

LoRaWAN предусматривает проверку подлинности сообщений, контроль их целостности и защиту от повторной передачи ранее перехваченных пакетов. Для криптографической защиты используются 128-битные ключи AES. Полезная нагрузка приложения шифруется между конечным устройством и сервером приложений.

При этом сквозное шифрование не следует отождествлять со сквозным контролем целостности. Спецификация LoRaWAN 1.1 предусматривает защиту целостности по отдельным участкам и рассматривает сетевой сервер как доверенный компонент. Поэтому необходимо отдельно оценивать его защищенность и обмен между серверными компонентами.

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

Практическая безопасность зависит и от обращения с ключами: общий секретный ключ для всей партии устройств или его передача в незащищенной таблице создают дополнительные риски. При успешном присоединении через OTAA формируются сеансовые ключи. Это не означает их автоматическую смену по расписанию: порядок повторного присоединения зависит от реализации системы.

NB-IoT использует механизмы безопасности сотовой сети, включая аутентификацию на основе SIM и защиту связи. Однако наличие SIM-карты не означает, что автоматически защищен весь маршрут до программы учета. Обмен между устройством и сервером приложения требует отдельной оценки.

Для его защиты могут использоваться TLS, DTLS или другие предусмотренные архитектурой механизмы. Их поддержку, настройку и проверку подлинности сервера необходимо подтвердить для выбранного устройства. Использование SIM как защищенного хранилища прикладных ключей требует совместимого решения, например IoT SAFE, и не является функцией любой SIM-карты по умолчанию.

Поэтому выбирать между LoRaWAN и NB-IoT только по принципу «что безопаснее» некорректно. Значение имеют архитектура проекта, распределение ответственности, управление ключами и защита серверной части. Собственная сеть дает больше возможностей управления, но одновременно требует ресурсов на сопровождение.

Как защитить данные после передачи

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

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

Для административного и удаленного доступа следует предусмотреть многофакторную аутентификацию. Доступ подрядчика должен действовать в согласованном объеме и в течение необходимого срока. Тот же принцип применим к программным интерфейсам обмена данными – API: интеграции, которая только получает показания, не нужны права на изменение настроек устройств.

При передаче дома от застройщика управляющей организации или ОСМД необходимо передать и управление системой учета. Этот процесс  включает административные права, документацию, перечень оборудования и порядок сопровождения. Доступы прежних подрядчиков следует пересмотреть, а не оставлять действующими по умолчанию.

^{Что защищать на каждом устройстве}

Что произойдет при потере связи или вмешательстве

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

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

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

Для системы следует заранее определить допустимый перерыв в поступлении данных и допустимую потерю истории. Резервную копию сервера тоже нужно проверять практически: можно ли восстановить базу, привязки приборов и настройки, сколько времени это занимает и кто выполняет восстановление.

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

Обновления и сопровождение на весь срок эксплуатации

Длительная работа от батареи не гарантирует столь же длительной программной поддержки. При выборе оборудования необходимо сопоставлять срок эксплуатации со сроками выпуска исправлений для радиомодулей, шлюзов и серверного программного обеспечения. Рекомендации GSMA рассматривают безопасность IoT на протяжении всего жизненного цикла решения.

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

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

Как Jooby RDC помогает контролировать состояние системы

Jooby RDC объединяет сбор показаний и работу с информацией о состоянии устройств. В Jooby RDC Dashboard предусмотрены уведомления о несанкционированном снятии, магнитном воздействии и низком заряде батареи. Доступность конкретных событий зависит от выбранной модели оборудования. Эти сведения помогают определять, какие точки учета требуют проверки.

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

Что проверить до массовой закупки

Оценку безопасности целесообразно завершать пилотом на реальном объекте. Для него нужны выбранные серийные устройства, рабочая сеть и запланированный способ интеграции. Демонстрация поступления одного показания подтверждает связь, но не показывает, как система переживет сбой или смену пользователей.

В программу приемки стоит включить несколько проверок:

• Ограничение доступа: убедиться, что пользователь одного объекта не видит данные другого, а отключенная учетная запись теряет доступ.
• Прослеживаемость изменений: проверить, фиксируются ли автор, время и содержание изменений привязки прибора, коэффициента пересчета и других значимых настроек.
• Восстановление учета: установить, какие записи доступны после перерыва связи, какие отсутствуют и не появляются ли дубли.
• Восстановление из копии: проверить возврат базы данных и необходимых настроек в работу за согласованное время.
• Реагирование на событие: убедиться, что уведомление получает ответственный сотрудник, а результат проверки сохраняется.

Эти испытания следует проводить на согласованном тестовом участке. Результаты нужно фиксировать в измеримых критериях: допустимое время восстановления, глубина доступного архива, полнота журнала и перечень разрешенных действий для каждой роли. Так требования к безопасности становятся проверяемыми условиями приемки.

Безопасная IoT-система позволяет установить происхождение показаний, ограничить доступ к ним и восстановить учет после сбоя в пределах подтвержденных возможностей оборудования. LoRaWAN и NB-IoT предоставляют механизмы защиты связи, а итоговый результат зависит от их реализации, настройки платформы и работы обслуживающих организаций. Выбирать решение стоит по возможностям всей системы: от управления ключами и правами до результатов пилота и условий сопровождения.