Всем привет! Мы - команда $mol_team, и нам есть что рассказать про безопасность. Недавно мы участвовали в хакатоне по кибериммунитету Касперского, от которого у нас остался любопытный артефакт, который будет небезынтересен всем, кого волнуют безопасные высоко доступные децентрализованные криптосистемы реального времени.

Задача

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

Ограничения

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

Концепция

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

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

---

Цели безопасности

Бизнес ценности, которые мы должны сохранять:

1. ???? Оператор видит корректную информацию о состоянии оборудовании в реальном времени, иначе может принять неверное решение, которое может привести к порче оборудования.

2. ???? Только авторизованный оператор может управлять оборудованием в соответствии с ролевой моделью. Человек без подготовки или полномочий может навредить работе системы.

3. ????‍♂️ Система выполняет свою функцию даже при выходе из строя или компрометации любого одного компонента системы. Поведение неуправляемой системы может быть сколь угодно плачевным.

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

5. ???? При истёкшем сроке лицензии, ПО продолжает работу, но его обновление не происходит.

6. ???? Действия пользователей системы в периметре заказчика не может привести к утечке ключевого ПО.

---

Предположения безопасности

Условия, которые должны быть обеспечены иными способами, чтобы наша система выполняла цели безопасности:

1. Оператор благонадёжен и ответственно выполняет все предназначенные для него регламенты, но как человек он может непреднамеренно ошибиться.

2. Каждый пользователь системы работает только под своей учётной записью.

3. В оборудовании, ОС и нашем собственном коде, нет закладок, но могут быть ошибки.

4. На каждом узле есть не доступное из вне хранилище ключей.

5. Технологическое оборудование исправно.

6. Пользователи имеют лишь удалённый доступ к системе управления.

---

Угрозы безопасности

Как мы защищаемся от различных нештатных ситуаций:

---

Функциональность

Каждый узел

• Выдаёт версию ПО.

• Выдаёт статус активности.

• Выдаёт статус обновления.

• Мониторит обновления своего ПО и лицензии.

• Проверяет лицензию и применяет обновление.

Сенсор

• Выдаёт сырое значение показателя.

• Показатель может требовать предварительной обработки:

  • Агрегация: среднее значение за определённое время.

  • Фильтрация: удаление не естественных всплесков.

Сенсоры ТЭЦ

• power_sensor - вырабатываемая мощность, текущее значение с фильтрацией.

• temp_sensor - температура воздуха, текущее значение с фильтрацией.

• freq_sensor - частота вращения турбины, агрегирует сигналы за минуту.

Драйвер

• Слушает управляющий сигнал.

• Выдаёт статус текущего действия.

Драйверы ТЭЦ

• power_driver - вырабатываемая мощность.

• main_driver - запуск/останов турбины.

---

Ролевая модель

---

Решение

Архитектура

Устойчивая: Все узлы минимум продублированы.

Крипрографическая: Все узлы объединены в единую одноранговую криптосеть.

Реплицированная: Все данные продублированы в распределённой БД между всеми заинтересованными узлами.

Реактивная: Прикладной код реагирует на изменение состояния БД, а не на события.

Доверенная: Вся информация аутентифицирована на входном узле.

Децентрализованная: Каждый узел независимо проверяет аутентификацию и авторизацию и общается напрямую лишь с одним девайсом (сенсором, драйвером, БД, пользователем и тд).

Минимизация не доверенного кода

• Свой протокол синхронизации - не нужны внешние сервисы типа Message Queue.

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

• Алгоритмический контроль доступа - не нужен централизованный аудитор запросов.

Алгоритмические гарантии

• Узлы не знают друг о друге, а взаимодействуют только с базой данных CROWDs, которая автоматически синхронизируется между узлами.

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

• Драйвер CROWDs отвергает любые неавторизованные или нецелостные юниты информации, получаемые как из внешних систем, так и из локальной базы данных.

• В изолированном периметре узла либо нет стороннего кода, либо он минимален.

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

• Задачи мониторят изменение состояния в реальном времени и отражают эти изменения на других состояниях или на подконтрольных системах.

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

• Реактивная архитектура с синхронизацией состояния проще и надёжнее событийной.

• Затруднительно обеспечивать доверие стороннему сервису.

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

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

Почему без выделенного монитора безопасности?

• Обход или компрометация монитора безопасности делает систему полностью беззащитной.

• Сервер синхронизации уже является аналогом централизованного монитора безопасности, так как проверяет аутентификацию и авторизацию всех проходящих через него юнитов информации.

• Драйвер CROWDs уже является мини-монитором безопасности, стоящим перед каждым узлом.

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

---

Узлы системы

Легенда: ✅ Желательно, ⭕ Бонус

---

Компоненты узлов

???? Не доверенные

???? Повышающие доверие

???? Доверенные

---

Варианты реализации

I - идеальное решение, если у нас будут все необходимые ресурсы на разработку инноваций.

P - проектное решение, которое мы готовы реализовать с текущими технологиями.

H - упрощённое решение запланированное на хакатон.

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

---

I - Идеал когда-нибудь

Полностью отказываемся от внешних зависимостей.

Выносим код синхронизации БД в отдельный процесс.

Пишем свой код работы с сокетами и исполняем его в отдельном процессе.

Пишем свою СУБД на компилируемом языке, оптимизированную для работы с CROWDs.

Controller - управляющий контроллер

Датчики, управляющие устройства, защитные устройства и тд.

Sync - сервер синхронизации

Обеспечивает связность узлов и гарантию доставки, попутно проверяя аутентификацию и авторизацию.

Persister - сервер персистентности

Бэкапит состояние БД в постоянное хранилище.

HMI - рабочее место

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

---

P - Проект хоть завтра

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

Используем PostgreSQL для постоянного хранения БД.

Controller - управляющий контроллер

Датчики, управляющие устройства, защитные устройства и тд.

Sync - сервер синхронизации

Обеспечивает связность узлов и гарантию доставки, попутно проверяя аутентификацию и авторизацию.

Persister - сервер персистентности

Бэкапит состояние БД в постоянное хранилище.

HMI - рабочее место

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

---

H - План на хакатон

Запускаем весь код в одном процессе виртуальной машины.

Controller - управляющий контроллер

Датчики, управляющие устройства, защитные устройства и тд.

Sync - сервер синхронизации

Обеспечивает связность узлов и гарантию доставки, попутно проверяя аутентификацию и авторизацию.

Persister - сервер персистентности

Бэкапит состояние БД в постоянное хранилище.

HMI - рабочее место

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

---

Рабочие сценарии

Успешная установка обновления

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

Установка обновления при истёкшей лицензии

Обновление ПО сохраняется в БД, но не устанавливается, пока лицензия не будет продлена.

Установка не аутентичных пакетов

Обновления ПО и лицензии с нарушенной целостностью отвергаются сразу и не попадают в систему.

Управление мощностью турбины

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

Приём данных с датчика скорости вращения

Состояние датчика может вносить в БД только его драйвер. Оператор видит гарантированно аутентичные показатели и время последнего их обновления.

---

Негативные сценарии

Компрометация узлов

Компрометация компонентов контроллера

I - Идеальный вариант

P - Проектный вариант

Дополнительно к идеальному:

H - Хакатоновский вариант

Дополнительно к проектному:

---

База Данных

Структура БД

Вся база данных (world) делится на кластеры (land). Каждый ленд помимо данных содержит всю необходимую для аутентификации и авторизации информацию, и синхроизируется атомарно.

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

За каждым приватным ключом алгоритмически закреплён 1 ленд, на который у владельца ключа есть полные права. Авторизованно писать в этот ленд может только он. Все сенсоры пишут свои показания в свои ленды, что исключает возможность подделки показаний другими узлами.

Каждый контроллер, допускающий управление, создаёт ещё один ленд (intent), права на управление которым есть только у администратора. Даже сам контроллер не может в него писать. А вот админ может выдавать права на запись в этот ленд операторам.

У оператора, которому разрешено менять intent, автоматически появляется интерфейс для управления контроллером. Контроллер слушает intent и реагирует на его изменения.

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

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

Реализация

Библиотеки

$hyoo_crowd - библиотека для реактивной работы с БД в памяти.

$hyoo_sync - библиотека для синхронизации БД с ФС и с другими узлами.

Технические детали

Unit - атомарный кусочек информации

Содержимое юнита

Каждый юнит содержит:

• Land - область атомарной синхронизации

• Auth - автор юнита

• Head+Self - идентификатор юнита

• Prev+Next - частичный порядок среди соседних юнитов

• Time+Aeon - время внесения данных в систему

• Size+Data - сырые данные

• Sign - авторская цифровая подпись

Устаревшие юниты отсеиваются, а оставшиеся упорядочиваются одинаково на всех узлах в соответствии с CvRDT подходом.

Протокол синхронизации

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

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

Каждый узел шлёт сердцебиения для поддержания соединения.

Долгое отсутствие сообщений от партнёра приводит к обрыву связи.

Обрыв связи - штатная ситуация, не влияющая на корректность синхронизации.

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

---

Запуск демонстрации

Исходные коды

Поднятие серверов

В докере

• Установлен docker и docker-compose.

docker compose up

Нативно

• Установлена NodeJS 18.

Установка зависимостей

npm install

Старт дев сервера

npm start

С него открываются пользовательские интерфейсы.

Старт сервера синхронизации

Сборка

npm start tec/server/start

Тут и далее тесты запускаются автоматически в процессе сборки:

Запуск

node tec/server/start/-/node.js sync=9090

Поднятие сервера персистенции

npm start tec/server/start
node tec/server/start/-/node.js sync=9091 masters=localhost:9090 db=postgres://user:password@host:5432/database

Поднятие эмуляторов сенсоров

npm start tec/power/service/start/-/node.js
node tec/power/service/start/-/node.js sync=9092 masters=localhost:9090 private_key=jWqTkjmwQ4Z-VnsM7PcJBQ8Dlh8h7YL3MsgQ_13nQy0qXfGWTgj_C02_QF1FMRnAf_PxWVi23a0GunNMNz8a-oHTRz1_ZsP2kMjAHZyvaSp33oibfNKB-sc59Hdf4PNV4

Для каждого экземпляра необходим свой private_key, его можно сгенерировать в админке, на странице "Private key".

Каждый запущенный экземпляр создаёт новый контроллер, идентификатор которого выводит в консоль при запуске:

Этот идентификатор надо добавить в админке, чтобы на дашборде появился интерфес работы с этим контроллером.

Запуск пользовательских интерфейсов

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

Дашборд оператора

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

open http://localhost:9080/tec/operator/dash/-/test.html

Консоль инженера поддержки

open http://localhost:9080/tec/operator/upload/-/test.html

Административная консоль

Приватный ключ администратора зашит в коде для удобства демонстрации.

open http://localhost:9080/tec/domain/admin/-/test.html

Консоль вендора

Приватный ключ вендора зашит в коде для удобства демонстрации.

open http://localhost:9080/tec/vendor/manager/-/test.html

---

Пользовательские интерфейсы

Для каждой роли у нас есть отдельные веб приложения для работы с системой:

---

Администрирование справочников

Реестр операторов

Приватный ключ оператора генерируется на его машине. На основе публичного ключа формируется его идентификатор, который выводится в шапке дашборда оператора. Администратор вносит этот идентификатор в систему и даёт ему понятное имя.

Реестр контроллеров

Приватный ключ контроллер генерирует и сохраняет у себя. На основе публичного ключа формируется его идентификатор, который выводится в консоли. Администратор вносит этот идентификатор в систему и даёт ему понятное имя.

---

Политики безопасности

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

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

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

---

Дашборд оператора

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

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

---

Консоль вендора

Упаковщик лицензий

Упаковщик обновлений

---

Сервисная консоль

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

---

Тестирование

Все тесты лежит в проекте в файлах с расширением test.ts и являются компонентными.

Тесты безопасности

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

Функциональные тесты

Запускаются автоматически при сборке соответствующих сервисов.

Сценарии проверяемые автоматически

Легенда: ✅позитивный, ❌негативный

Тесты сценариев работы оператора:

✅ Аутентичное отображение показаний сенсора.

✅ Авторизованное управление состоянием драйвера.

❌ Попытка неавторизованного управления состоянием драйвера.

Не автоматизированные сценарии

Легенда: ✅позитивный, ❌негативный

❌ Попытка установки обновления на контроллер без лицензии.

Поднять инфраструктуру в докере.

Внести изменения в код /tec/power/service/start/start.node.ts добавив вывод в консоль cлова TEST при запуске.

Собрать сервис по инструкции.

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

Установить тип пакета в "Power Driver".

Загрузить собранные файлы модифицированного сервиса.

Выгрузить пакет с обновлением ПО.

Открыть сервисную консоль.

Загрузить пакет с обновлением ПО.

Убедиться, что контроллер сообщил об истечении срока лицензии и не перезапустился.

❌ Попытка установки обновления на контроллер с не валидной лицензией.

Поднять инфраструктуру в докере.

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

Установить время истечения лицензии на вчера.

Выгрузить пакет с лицензией.

Внести изменения в код /tec/power/service/start/start.node.ts добавив вывод в консоль cлова TEST при запуске.

Собрать сервис по инструкции.

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

Установить тип пакета в "Power Driver".

Загрузить собранные файлы модифицированного сервиса.

Выгрузить пакет с обновлением ПО.

Открыть сервисную консоль.

+ Загрузить пакет с лицензией.

Загрузить пакет с обновлением ПО.

Убедиться, что контроллер сообщил об истечении срока лицензии и не перезапустился.

✅ Установка авторизованного обновления на контроллер с валидной лицензией.

Поднять инфраструктуру в докере.

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

Установить время истечения лицензии на завтра.

Выгрузить пакет с лицензией.

Внести изменения в код /tec/power/service/start/start.node.ts добавив вывод в консоль cлова TEST при запуске.

Собрать сервис по инструкции.

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

+ Установить тип пакета в "Power Driver".

Загрузить собранные файлы модифицированного сервиса.

Выгрузить пакет с обновлением ПО.

Открыть сервисную консоль.

Загрузить пакет с лицензией.

Загрузить пакет с обновлением ПО.

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

✅ Установка продления лицензии с авто установкой ожидавших обновлений.

Поднять инфраструктуру в докере.

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

Установить время истечения лицензии на завтра.

Выгрузить пакет с лицензией.

Внести изменения в код /tec/power/service/start/start.node.ts добавив вывод в консоль cлова TEST при запуске.

Собрать сервис по инструкции.

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

Установить тип пакета в "Power Driver".

Загрузить собранные файлы модифицированного сервиса.

Выгрузить пакет с обновлением ПО.

Открыть сервисную консоль.

Загрузить пакет с обновлением ПО.

Убедиться, что контроллер сообщил об истечении срока лицензии и не перезапустился.

Загрузить пакет с лицензией.

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

❌ Попытка установки неавторизованной лицензии.

Поднять инфраструктуру в докере.

Поменять зашитый в коде консоли вендора ключ на свеже сенерированный.

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

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

Установить время истечения лицензии на завтра.

Выгрузить пакет с лицензией.

Открыть сервисную консоль.

Убедиться в появлении ошибки при попытке загрузить пакет с лицензией.

❌ Попытка установки неавторизованного обновления.

Поднять инфраструктуру в докере.

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

Установить время истечения лицензии на завтра.

Выгрузить пакет с лицензией.

Поменять зашитый в коде консоли вендора ключ на свеже сенерированный.

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

Внести изменения в код /tec/power/service/start/start.node.ts добавив вывод в консоль cлова TEST при запуске.

Собрать сервис по инструкции.

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

Установить тип пакета в "Power Driver".

Загрузить собранные файлы модифицированного сервиса.

Выгрузить пакет с обновлением ПО.

Открыть сервисную консоль.

Загрузить пакет с лицензией.

Убедиться в появлении ошибки при попытке загрузить пакет с обновлением ПО.

Убедится, что сервис никак не отреагировал на попытку обновления.

---

Команда $mol_team

---

Результаты

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

Наш разбор нашего решения

Разбор организаторами нашего решения

Наши пояснения к разбору

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

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

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

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

У нас нет блокчейна, но есть CRDT и асимметричная криптография.

Разбор организаторами решения победителей

Да, косяк на косяке. Всё куплено. Верните мои нервы!

Послесловие

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

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

---

Актуальный оригинал на $hyoo_page.