Безопасность данных в АСКУЭ и АСКУВТ

03.11.2026

Автор статьи: Леонид Другов


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

А теперь вспомните, что именно лежит в этой базе. Деньги: по показаниям выставляются счета. Персональные данные: ФИО, адреса и лицевые счета жильцов. И кнопки, которыми можно ограничить мощность в чужой квартире. Если собирать такую систему по принципу «потом доделаем», каждая из этих трёх вещей однажды выстрелит.

Мы в ENVIRO внедряем и обслуживаем АСКУЭ и АСКУВТ, так что насмотрелись всякого. В этой статье расскажем историю одного Пети и разберём, где система учёта протекает на каждом уровне, от прибора до личного кабинета. Объясним, почему авторизацию мы не стали писать сами, а взяли Keycloak. А в конце дадим чек-лист, по которому свою систему можно проверить за 15 минут.

Статья для УК, застройщиков, энергосбытов и всех, кому всё это эксплуатировать.

Содержание

  1. История Пети: как самописная авторизация превращается в проблему

  2. Почему так происходит: рынок и тренды

  3. Где уязвима система учёта: 6 уровней

  4. Как устроена защищённая АСКУЭ/АСКУВТ

  5. Кейс: переход на защищенную авторизацию в УК

  6. Мнения экспертов

  7. Чек-лист: 11 пунктов безопасности системы учёта

  8. Почему стоит выбрать «Телеметрию АТм»

  9. Вопросы и ответы

1. История Пети

Представьте обычного Петю. Он — айтишник в управляющей компании, единственный ИТ-специалист в штате. Петя чинит принтеры, поддерживает сайт и настраивает резервное копирование баз данных. Хороший, толковый специалист.

Однажды директор подходит к Пете и говорит: «Петь, в четырёх домах установлена система АСКУЭ. Мне нужно видеть показания со всех домов в одном месте. Сможешь реализовать?»

Петя берется за задачу. Сбор данных с УСПД он настраивает за неделю, а страницу с таблицей показаний верстает за пару дней. Остаётся вопрос аутентификации. Петя создает в базе данных таблицу users с полями для логина и пароля, разрабатывает форму входа и механизм проверки. Готово. Работает? Работает.

Пароли

Через месяц Петя читает статью про утечки и понимает, что хранить пароли открытым текстом как-то неприлично. Он прогоняет их через MD5, и теперь в базе лежат красивые строки вроде e10adc3949ba59abbe56e057f20f883e.

Это, кстати, 123456. Быстрые хеши без «соли» раскрываются по готовым таблицам за секунды, так что при утечке бэкапа большинство паролей восстанавливаются без особого труда. Заодно форма входа терпеливо принимает тысячу попыток в минуту: ограничений Петя не делал, зачем? Работает же.

Диспетчеры

Потом в систему приходят диспетчеры. Их шестеро, работают посменно, текучка. Заводить каждому логин, а потом удалять - морока. Петя создаёт одну учётку dispatcher, а пароль пишет на стикере и клеит на монитор в диспетчерской.

Через полгода жилец из 47-й квартиры приходит с претензией. Соседи платят копейки, а ОДН по дому выросла, и доплачивать приходится всем. Петя открывает историю и видит, что показания нескольких квартир кто-то руками поправил в меньшую сторону. В журнале написано: «изменено: dispatcher». Кто из шестерых, в какую смену и зачем, уже не узнать. Зато работает.

Чужие дома

Дальше директор решает, что инженер каждого дома должен видеть только свой дом. Петя добавляет фильтр в меню: инженер Иванов теперь видит в списке только дом № 12. Красота.

Только адрес страницы отчета выглядит как /report?building=12. Если поменять 12 на 13, откроется дом, который Иванову видеть не положено: фильтр есть только в меню, а сервер честно отдаёт всё, о чём попросят. У разработчиков это называется IDOR (небезопасная прямая ссылка на объект), и в рейтинге OWASP Top 10 вся эта категория ошибок, нарушение контроля доступа, стоит на первом месте. Но кто ж будет подставлять цифры в адресную строку.

Роли

Бухгалтеру иногда нужно вносить ручные показания: счетчик сломался, жилец принёс фото. В Петиной системе ровно две роли: «пользователь» и «администратор». Ручной ввод доступен только администратору. Значит, бухгалтер становится администратором.

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

Подрядчик

Оборудование в домах обслуживает сервисная организация. Её инженеру нужен доступ, и Петя, не мудрствуя, выдаёт ему тот же admin. Инженер уходит на другой проект, а пароль остается прежним. Если его сменить, придется рассылать новый всем, кто им пользуется. А кто им пользуется, Петя уже точно не помнит.

Excel

Последний штрих. Бухгалтерия в кабинет заходить не хочет, ей удобнее в Excel. Раз в месяц Петя выгружает файл: ФИО, адрес, лицевой счёт, показания. Файл уходит по почте, оттуда в мессенджер, оттуда на личный ноутбук. В терминах 152-ФЗ это неконтролируемое распространение персональных данных, а штрафы за утечки теперь зависят от того, сколько человек пострадало.

Мораль

Обратите внимание: Петя нигде не ошибся по глупости. Каждое решение было разумным в моменте: сделаем попроще, потом доработаем. Просто в системах учёта «потом» наступает в день первого спора с жильцом о показаниях или первого письма из Роскомнадзора.

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

2. Почему так происходит

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

Счётчиков стало больше, и все они в сети

С 1 января 2022 года устанавливать можно только интеллектуальные приборы учета электроэнергии, а гарантирующие поставщики и сетевые организации обязаны давать потребителям доступ к интеллектуальным системам учёта (КонсультантПлюс, ПП РФ № 890). Новые дома сдаются с АСКУЭ по умолчанию, воду и тепло всё чаще подключают к АСКУВТ.

Для учёта это отлично. Для безопасности — тысячи новых устройств в сети, и у каждого свой канал: GSM-модем, NB-IoT, LoRaWAN, RS-485 через шлюз. У канала свои ключи и пароли, и все они должны где-то храниться. Часто в той же таблице, что и у Пети.

А ещё в учёте до сих пор встречается Modbus, в котором аутентификации нет в принципе: устройство выполнит команду любого, кто до него достучался. По данным Cato Networks, только за сентябрь–ноябрь 2025 года подозрительные запросы по Modbus/TCP уходили на 14 426 IP-адресов в 70 странах (SecurityLab). Иными словами, открытые порты промышленных устройств кто-то систематически ищет и простукивает.

Систему выбирают один раз, а эксплуатируют годами

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

При выборе естественно смотреть на цену оборудования и сроки запуска. Но безопасность определяется не в день приёмки, а в эксплуатации. Кто будет обновлять ПО? Кто заведёт учётную запись новому диспетчеру и отключит уволенному? Кто заметит, что прибор замолчал? Если при выборе на эти вопросы никто не ответил, отвечать на них потом придётся Пете. Тому самому, который в УК один на всё.

Поэтому выбирать стоит не только систему, но и того, кто будет её сопровождать. А требования к безопасности, записанные в ТЗ (о них в разделе 4.1), на этапе проекта обходятся дешевле любой доработки после сдачи дома.

Атакуют уже не только заводы

Принято думать, что хакерам интересны АЭС и нефтепроводы, а счетчик в подъезде никому не нужен. Цифры говорят другое. Во втором квартале 2026 года вредоносные объекты блокировались на 15% компьютеров АСУ в России и на 19% в мире. Автоматизация зданий при этом оказалась в числе отраслей, где доля атак шифровальщиков за квартал выросла заметнее всего (Kaspersky ICS CERT).

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

За утечки теперь штрафуют всерьёз

Раньше штраф за утечку персональных данных был сопоставим с ценой ноутбука. С 30 мая 2025 года действует закон 420-ФЗ, и суммы теперь зависят от того, сколько человек затронуло:

Чей данные утекли

Штраф для юрлица

1–10 тыс. человек

3–5 млн ₽

10–100 тыс. человек

5–10 млн ₽

более 100 тыс. человек

10–15 млн ₽

повторная утечка

1–3% годовой выручки, но не менее 25 млн и не более 500 млн ₽


Источники: Харант, PPT.ru.

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

И это не теория. В 2024 году Роскомнадзор зафиксировал 135 утечек, в которых оказалось более 710 млн записей о россиянах, в 2025-м — 118 утечек и более 52 млн записей (www1.ru, по данным РКН).

Итого

Устройств стало больше, выбирают их по цене, атакуют их по-настоящему, а штрафуют за них теперь на миллионы. На этом фоне Петино «потом доработаем» перестаёт быть анекдотом. Давайте посмотрим, где именно течет.

3. Где уязвима система учёта

Петины проблемы жили в веб-кабинете, но кабинет — это только верхушка. Показание проходит длинный путь: счётчик → УСПД или модем → канал связи → сервер опроса → база → кабинет → бухгалтерия. Сломать можно на любом шаге, и самая надёжная авторизация не поможет, если счетчик можно переписать напрямую. Пройдемся по цепочке снизу вверх.

3.1. Прибор учёта и УСПД

У современного счётчика есть пароль. Вот только пароль этот часто напечатан в паспорте прибора, одинаков для всей партии и выглядит как 000000 или 111111. На пусконаладке его не меняют: настраивать тысячу уникальных паролей долго, а дом надо сдавать в пятницу.

А за паролем скрывается не только чтение показаний. Через тот же интерфейс счетчику можно:

  • перевести часы, и тогда ночной тариф внезапно начинается в обед;

  • поменять настройки тарифного расписания;

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

На стороне обороны тоже кое-что есть. Современные приборы ведут журнал событий: вскрытие крышки, коррекция времени, смена параметров. Протокол СПОДЭС, основанный на DLMS/COSEM, поддерживает раздельные уровни доступа и шифрование. Но и журнал, и шифрование работают, только если их включили и если кто-то их читает. А рядом с СПОДЭС в одном доме мирно живут теплосчётчики на Modbus и M-Bus, где паролей нет вовсе.

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

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

3.2. Каналы связи

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

Рабочих вариантов защиты три:

  1. Приватная сеть оператора (частный APN). SIM-карты модемов видны только из вашей сети, из интернета до них не достучаться.

  2. VPN до объекта. Трафик от УСПД до сервера идёт по зашифрованному туннелю.

  3. Обратная схема. Не сервер стучится к модему, а модем сам устанавливает соединение с сервером. На модеме нет открытых портов, значит, не во что стучаться.

У обратной схемы есть нюанс: сервер должен понять, кто к нему подключился. Если модем представляется одним серийным номером или IMEI, то любой, кто знает этот номер, может прикинуться счётчиком и прислать свои «показания».

С LoRaWAN история похожая. Сам протокол шифрует данные, но только пока ключи устройств секретны. Если ключи для всей партии датчиков лежат в Excel-файле у монтажника, шифрование уже никого не защищает.

3.3. Сервер и база данных

Чтобы опрашивать счетчики, серверу нужны их пароли. Значит, пароли где-то лежат. У Пети они лежат в таблице devices, в колонке password, открытым текстом. Рядом колонка ip и колонка port. Удобно: один дамп базы, и у злоумышленника есть полный список счётчиков с адресами и ключами.

Ещё несколько классических находок:

  • сервис опроса ходит в базу под суперпользователем и при желании может удалить все таблицы, хотя должен только записывать показания;

  • брокер сообщений между сервисами доступен снаружи со стандартным логином и паролем из документации;

  • сервер опроса и веб-кабинет живут на одной машине, и дыра в сайте сразу дает доступ к управлению оборудованием;

  • резервные копии есть, но лежат на том же сервере и не зашифрованы.

3.4. Веб-кабинет

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

  • токен входа не имеет срока годности, и уволенный сотрудник остается в системе, даже если его удалили из списка;

  • секретный ключ для подписи токенов лежит в репозитории с исходниками.

Каждую из этих проблем можно исправить по отдельности. Но проще не писать авторизацию самому, и к этому мы вернёмся в разделе 4.4.

3.5. Выгрузки и передача данных

Самая защищённая система заканчивается там, где данные из нее выгрузили. Excel-файл с ФИО и лицевыми счетами не знает ничего про роли и права доступа. Его нельзя отозвать, нельзя узнать, кто его открывал, и нельзя гарантировать, что его удалили со всех ноутбуков. Почта, общие сетевые папки и рабочие чаты в мессенджерах — именно так данные и утекают чаще всего, без всяких хакеров.

3.6. Человеческий фактор

И наконец люди. Стикер с паролем на мониторе, один логин на смену, пароль админа, который знают три подрядчика и два уволенных сотрудника. И журнал действий, которого нет, а если есть, то в нём все записи от имени admin. Техника тут не спасёт, если система делает неправильное поведение удобнее правильного. Значит, система должна быть устроена наоборот.

Сводная таблица

Уровень

Угроза

Чем грозит

Чем закрывается

Прибор и УСПД

Заводские пароли, команды записи доступны всем

Подмена времени и тарифов, отключение квартир

Доступ к прибору только с сервера опроса, разделение уровней доступа, чтение журнала событий

Канал связи

Белый IP и открытый порт на модеме, ключи LoRaWAN в открытом файле

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

Частный APN, VPN, обратная схема подключения

Сервер и БД

Пароли устройств открытым текстом, лишние права сервисов

Компрометация всего парка сразу

Шифрованное хранилище секретов, минимальные права, разделение сегментов сети

Веб-кабинет

Самописная авторизация, IDOR, две роли

Доступ к чужим домам и опасным командам

Готовая система авторизации, детальные роли, проверка доступа на сервере

Выгрузки

Excel с ПДн по почте и в мессенджерах

Утечка и штраф по 420-ФЗ

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

Люди

Общие учётки и пароли, нет журнала

Невозможно установить виновного, доступ у уволенных

Персональные учетные записи, единый вход, журнал всех действий


4. Как устроена защищённая АСКУЭ/АСКУВТ

Хорошая новость: ничего из того, о чём пойдёт речь, не требует ни космических бюджетов, ни отдела безопасности из десяти человек. Нужно только подумать о безопасности до того, как придёт директор с фразой «Петь, сделаешь?». Ниже — как мы это делаем в платформе «Телеметрия АТм».

4.1. Безопасность начинается с ТЗ

Если чего-то нет в техническом задании, на приёмке этого тоже не будет. Поэтому застройщику и УК стоит вписать в ТЗ на систему учёта хотя бы такой минимум:

  • оборудование принимает подключения только от сервера опроса: прибор сам выходит на сервер или пускает к себе только его IP-адрес;

  • пароли доступа к приборам меняются, если это позволяет регламент обслуживания, и известны системе опроса, а не одному монтажнику;

  • у каждого сотрудника своя учётная запись, общих логинов нет;

  • роли описаны заранее, опасные действия вынесены в отдельные права;

  • все изменения показаний и настроек пишутся в журнал с указанием автора;

  • после сдачи объекта учётные записи монтажников отключаются.

Шесть строчек в ТЗ, а Петина история заканчивается, не начавшись.

4.2. Закрытая сеть передачи данных

Правило простое: до счетчика должен достучаться только сервер опроса. У нас это работает по двум схемам. В основной линии приборов и УСПД сами подключаются к серверу ENVIRO как клиенты, и на объекте нет ни одного открытого порта, до которого можно дотянуться из интернета. Если же сервер подключается к оборудованию сам, на УСПД и линиях включён белый список: соединение принимается только с IP-адреса сервера опроса, а все остальные просто не проходят. Частный APN и VPN тоже рабочие варианты, если этого требует схема объекта.

Внутри самой системы правило то же. Сервис опроса, база данных и брокер сообщений не смотрят в интернет. Каждый сервис ходит в базу под своим пользователем и с теми правами, которые ему нужны.

4.3. Целостность показаний

Вспомним жильца из 47-й квартиры. Ему нужен ответ на простой вопрос: откуда взялось это число. В АТм ответ такой: это ровно то, что прислал прибор учёта. А рядом лежит история его показаний за длительный период, так что видно, как потребление менялось от месяца к месяцу. Спорить с цифрой, за которой стоит сам счётчик и несколько лет истории, заметно сложнее, чем с строчкой в таблице, которую кто-то поправил руками.

Ручные показания вносит только роль «Поверитель», и каждое такое действие привязано к конкретному человеку. А не к учетке dispatcher, как у Пети.

4.4. Почему мы выбрали Keycloak, а не стали писать свою авторизацию

А теперь признание. Наш сайт тоже начинал со своей таблицы пользователей. Сделано было аккуратно, на стандартном ASP.NET Identity, без MD5 и стикеров. Но чем больше становилось объектов, ролей и сервисов, тем чаще мы залатывали те же дыры, что и Петя. В какой-то момент стало понятно: авторизация — это отдельный продукт, и писать его каждый раз заново не нужно.

Идея такая. Приложение вообще не знает паролей. Пользователь входит через отдельный сервер авторизации (identity provider), получает подписанный токен со списком своих ролей и с ним приходит в систему. Хранение паролей, защита от перебора, срок жизни сессий и второй фактор — всё это забота сервера авторизации, а не каждого приложения. Осталось выбрать, какой именно.

С чем сравнивали

У нас было четыре жёстких требования. Развёртывание на своих серверах, потому что персональные данные должны оставаться в России. Открытые стандарты вместо привязки к вендору. Изоляция заказчиков друг от друга. И лицензия, которая позволяет поставлять систему клиентам, не покупая отдельную лицензию на каждого.

Решение

Что это

Лицензия

На своих серверах

Единый вход в несколько систем

Почему не подошло

Своя разработка

Таблица пользователей и форма входа

—

Да

Нет, пишется с нуля

Вся история Пети. И дорабатывать её придётся вечно

ASP.NET Core Identity

Библиотека внутри приложения

Бесплатно, часть .NET

Да

Нет: у каждого приложения своя база пользователей

Ровно то, что у нас было. Хорошо для одного сайта, плохо для платформы

Duende IdentityServer

Фреймворк для сборки своего сервера авторизации на .NET

Коммерческая; бесплатно только при выручке до $1 млн

Да

Да

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

Auth0 / Okta

Облачный сервис авторизации

Подписка

Нет, только облако

Да

Данные хранятся за рубежом, а в марте 2022 года сервис отключил аккаунты в России

Blitz Identity Provider, Avanpost, Indeed AM

Корпоративные системы российских вендоров

Коммерческая, стоимость по запросу

Да

Да

Рассчитаны на крупные корпорации и госсектор. Для УК на несколько домов — избыточно и дорого в пересчете на каждую инсталляцию

Keycloak

Готовый сервер авторизации с открытым кодом

Apache 2.0, бесплатно

Да

Да

Выбрали. Детали ниже


Источники: Keycloak, условия Duende Community Edition, Хабр об уходе Okta и Auth0, аналоги Blitz Identity Provider.

Keycloak разрабатывается при участии Red Hat, с 2023 года входит в Cloud Native Computing Foundation и распространяется под лицензией Apache 2.0. На практике это значит, что проект не исчезнет завтра, его код можно проверить, а развернуть его можно у себя и у каждого заказчика без лицензионных отчислений.

Что это дало на практике

Открытые стандарты. Вход работает по OpenID Connect, система принимает подписанные JWT-токены. У сайта и API свои клиенты в Keycloak, и API проверяет, что токен выпущен именно для него. Анонимного доступа к данным нет: пользователь с валидным токеном, но без роли, не увидит ничего.

Отдельное пространство на каждого заказчика. У каждой инсталляции свой realm — изолированный набор пользователей, ролей и настроек. Пользователи одной УК физически не пересекаются с пользователями другой.

Роли под реальные задачи. Вместо Петиных «пользователь / администратор» в АТм больше десятка ролей, и каждая дает ровно свой набор действий:

  • Поверитель вносит ручные показания и архивирует источники данных;

  • Управленец нагрузкой настраивает ограничение мощности; кроме него, это может только администратор;

  • Настройщик топологии добавляет и удаляет устройства;

  • Редактор реестра объектов ведет здания и помещения;

  • Оператор мониторинга оборудования видит неисправные устройства;

  • Менеджер пользователей заводит сотрудников и выдает им права.

Бухгалтеру больше не нужно становиться администратором, чтобы внести одно показание. А кнопка ограничения мощности просто не показывается тем, кому она не положена. И сервер её таким пользователям тоже не выполнит.

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

Разграничение по объектам. Сотруднику выдаётся доступ к конкретным зданиям, и в списках, мониторинге и статистике он видит только их. Инженеру дома № 12 дом № 13 не нужен.

Техподдержка без общих паролей. Помните инженера подрядчика с учеткой admin? У нас сотрудники поддержки входят в систему заказчика своей корпоративной учётной записью через центральный Keycloak (identity brokering), а роли приезжают автоматически. Уволился сотрудник — его учетку отключают в одном месте, и доступ пропадает сразу везде. Никаких рассылок нового пароля.

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

Переезд без сброса паролей. Самая неприятная часть любой смены авторизации — письмо «уважаемые пользователи, смените пароль». Мы его не писали. Пользователь входит старым логином и паролем, система проверяет их по старой базе и в тот же момент создаёт ему учётную запись в Keycloak с теми же ролями. Люди переехали и не заметили.

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

Честно о минусах

Keycloak не волшебная таблетка. Это отдельный сервис, который нужно развернуть, обновлять и мониторить. У него сотни настроек, и неправильно настроенный Keycloak защищает не лучше Петиной таблицы. Да и проверку прав на конкретные объекты он за приложение не сделает: он скажет, кто пришёл и с какими ролями, а пускать ли его в дом № 13, решает уже система. Поэтому мы и держим его настройку на стороне интегратора, а не сваливаем на УК.

4.5. Персональные данные жильцов

Лучший способ не допустить утечку персональных данных — не давать их тем, кому они не нужны. Настройщику топологии не нужны ФИО жильцов, ему достаточно номера квартиры и серийника счётчика. Бухгалтерии нужны показания, но она получает их в кабинете под своей учётной записью и только по своим домам, а не файлом в почте. Данные хранятся на серверах в России, сервер авторизации тоже.

4.6. Мониторинг и сервис

Безопасность не делается один раз на приёмке. Устройства выходят из строя, сотрудники меняются, выходят обновления. В АТм есть мониторинг неисправных устройств и проверка полноты данных по дому. Счетчик, который вдруг замолчал или начал присылать странное, заметен сразу, а не в конце месяца. Остальное закрывает сервисное обслуживание: диагностика, обновления и контроль оборудования на объекте.

5. Кейс: как УК ушла от Петиной схемы

Кейс собирательный: он объединяет типовые ситуации с наших объектов, цифры округлены.

Ситуация. Управляющая компания в Екатеринбурге: четыре ЖК, около 1 600 квартир и 5 000 точек учета электроэнергии, воды и тепла. Кабинет показаний был самописным, диспетчеры работали под общей учетной записью, сервисный инженер подрядчика заходил под тем же admin, что и директор. Бухгалтерия раз в месяц получала показания с ФИО и лицевыми счетами в Excel по почте. Поводом для перемен стал спор с жильцом о ручной корректировке показаний, в котором УК не смогла показать, кто и когда их изменил.

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

Решение.

  1. Провели аудит: составили перечень оборудования, проверили, что из него видно из интернета, собрали список всех, кто знал пароль admin.

  2. Закрыли канал до УСПД: наружу больше не смотрит ни один порт оборудования.

  3. Перенесли сбор и хранение показаний на «Телеметрию АТм», а вход — на Keycloak в отдельном realm УК.

  4. Завели каждому сотруднику УК персональную учётную запись в Keycloak, а старый самописный кабинет вместе с общими логинами отключили.

  5. Заменили общую учётку диспетчеров шестью персональными, ручной ввод отдали роли «Поверитель», ограничение мощности — двум сотрудникам с ролью «Управленец нагрузкой».

  6. Инженерам выдали доступ только к их домам, а бухгалтерию перевели на кабинет вместо Excel.

Результат.

Показатель

До

После

Общие учётные записи

2 (admin, dispatcher)

0

Отзыв доступа уволенного сотрудника

не делался

несколько минут, в одном месте

Изменения показаний с известным автором

неизвестно

100%

Файлы с ПДн по почте в месяц

4 (по одному на дом)

0

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

2–3 рабочих дня

несколько часов

Порты оборудования, доступные из интернета

есть

0


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

6. Мнения экспертов

Мы в ENVIRO считаем, что в системе учёта самая дорогая уязвимость — не взлом, а отсутствие ответа на вопрос «кто это сделал». Когда у каждого сотрудника своя учетная запись и свои права, а все действия пишутся в журнал, спор с жильцом решается за пять минут. Когда нет, он не решается вообще.

И не только мы так думаем.

OWASP, международное сообщество по безопасности веб-приложений, в последней редакции рейтинга OWASP Top 10:2025 снова ставит нарушение контроля доступа на первое место. Такие ошибки в той или иной форме нашлись во всех протестированных приложениях. В списке типовых ошибок прямо назван случай из истории Пети: доступ к чужой записи через подмену её идентификатора в адресе (OWASP Top 10:2025, A01).

Kaspersky ICS CERT регулярно выделяет автоматизацию зданий среди отраслей с самой высокой долей атак: так было и в первом полугодии 2022 года (пресс-релиз «Лаборатории Касперского»), так же и во втором квартале 2026-го, когда речь шла о шифровальщиках (отчёт Kaspersky ICS CERT).

Законодатель смотрит на проблему с другой стороны, но приходит к тому же. С 30 мая 2025 года штраф за утечку зависит от числа пострадавших, а за повторную утечку считается от выручки (PPT.ru о 420-ФЗ). То есть общая учетка и Excel в почте теперь не просто плохая практика, а финансовый риск.

7. Чек-лист: 11 пунктов безопасности системы учёта

Возьмите свою систему и пройдитесь по списку. Каждое «нет» или «не знаю» — это то место, где у вас живёт свой Петя.

Оборудование и сеть

  • До приборов и УСПД может подключиться только сервер опроса: прибор сам выходит на сервер, включен белый список IP, частный APN или VPN.

  • Известно, какие пароли стоят на приборах, и они хранятся в системе опроса, а не на стикере.

  • Ключи LoRaWAN и пароли устройств не лежат в открытых файлах и таблицах.

Сервер и данные

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

  • Резервные копии зашифрованы и хранятся не на том же сервере.

  • Персональные данные жильцов хранятся в России и не рассылаются файлами.

Доступ и люди

  • У каждого сотрудника своя учётная запись, общих логинов нет.

  • Опасные действия (ручные показания, ограничение мощности, удаление устройств) вынесены в отдельные роли.

  • Сотрудник видит только свои объекты, и сервер проверяет это, а не только меню.

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

  • Любое изменение показаний и настроек можно найти в журнале: кто, когда, что было и что стало.

Если все 11 галочек стоят — поздравляем, вашему Пете можно спокойно чинить принтер.

8. Почему стоит выбрать «Телеметрию АТм»

Насчитали в чек-листе больше двух «не знаю»? Это не приговор, а список дел. И большую часть этого списка закрывает сама система учёта, если она правильно устроена. В «Телеметрии АТм» всё, о чём мы говорили в статье, уже есть:

  • Оборудование не торчит в интернет. Приборы сами подключаются к нашему серверу, а там, где подключаемся мы, УСПД пускают только IP сервера опроса.

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

  • Роли под реальные задачи. Больше десятка ролей, а опасные действия вроде ручного ввода показаний или ограничения мощности вынесены в отдельные права.

  • Каждому — свои объекты. Сотрудник видит только те здания, к которым ему выдан доступ.

  • Ответ жильцу за пять минут. История показаний за длительный период и журналы событий по устройствам.

  • Неисправности видны сразу. Мониторинг устройств показывает замолчавший прибор, а не ждёт конца месяца.

  • Данные в России. Показания, персональные данные и сервер авторизации работают на серверах в России.

Мы берём на себя весь цикл АСКУЭ и АСКУВТ: проектирование, поставку оборудования, монтаж, пусконаладку и сервисное обслуживание. Для нового дома внедрим систему с нуля, и требования к безопасности будут в ТЗ с первого дня. Для действующего переведем сбор показаний на АТм, и там, где оборудование это позволяет, без замены счётчиков.

Расскажите о своем объекте, и мы предложим схему подключения к «Телеметрии АТм» и рассчитаем стоимость. Оставьте заявку на envr.biz, позвоните по номеру +7 (343) 253-58-99 или напишите на mail@envr.biz.

9. Вопросы и ответы

Обязана ли УК защищать данные с приборов учёта?

Если в системе есть ФИО, адреса или лицевые счета жильцов, УК выступает оператором персональных данных по 152-ФЗ и отвечает за их защиту, в том числе штрафами за утечку. За сами показания отдельного штрафа нет, но их подмена оборачивается прямыми денежными потерями и спорами с жильцами.

Являются ли показания счётчиков персональными данными?

Само по себе число «1 234 кВт·ч» человека не определяет. Но в связке с адресом, лицевым счётом или ФИО показания становятся сведениями о конкретном человеке. По профилю потребления даже видно, когда людей нет дома. Поэтому мы исходим из того, что защищать нужно всю связку. Точную юридическую квалификацию для вашего случая лучше уточнить у юриста.

Что безопаснее: GSM, LoRaWAN или проводной RS-485?

Безопасность зависит не столько от канала, сколько от настройки. RS-485 сложнее атаковать удалённо, но данные всё равно уходят наружу через шлюз или модем. LoRaWAN шифрует данные, пока ключи устройств секретны. GSM надежен в частной сети оператора или с VPN, и самый уязвимый в варианте «белый IP и открытый порт».

Можно ли защитить уже установленную систему без замены оборудования?

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

Зачем отдельная система авторизации, если в кабинете и так есть логин и пароль?

Логин и пароль — это только входная дверь. А ещё нужны безопасное хранение паролей, защита от перебора, срок жизни сессий, роли, второй фактор, единый вход для поддержки и отзыв доступа в одном месте. Каждую из этих вещей можно написать самому, как Петя. А можно взять проверенный сервер авторизации, где всё это уже есть и поддерживается сообществом.

Источники

Проверьте безопасность вашей системы учёта вместе с ENVIRO

Безопасность АСКУЭ и АСКУВТ начинается с правильной организации всей системы: от передачи данных с приборов до доступа сотрудников к показаниям. Даже если оборудование уже установлено, многие риски можно устранить без замены счётчиков и масштабной модернизации.

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

Оставьте заявку через форму ниже. Расскажите о вашем объекте, и мы свяжемся с вами, чтобы обсудить задачи, предложить подходящую схему подключения к «Телеметрии АТм» и рассчитать стоимость внедрения.




Оставить заявку

Ваше имя
Телефон
Компания
Что вас интересует?