Этот проект представляет собой заготовку, MVP, для задачи "ПЛК" и предназначен для получения представления о интерфейсе взаимодействия компонентов, возможных способах реализации их минимального функционала, его объеме и т.д. Таким образом, пример является отправной точкой работы, но не обязательно является образцом "хорошо" или "правильно" и может быть изменен и расширен участниками в своих реализациях.
Применять только в учебных целях. Данных код может содержать ошибки, авторы не несут никакой ответственности за любые последствия использования этого кода. Условия использования и распространения - MIT лицензия (см. файл LICENSE).
Данный пример разработан и проверен на ОС Ubuntu 20.04.5, авторы предполагают, что без каких-либо изменений этот код может работать на любых Debian-подобных OS, для других Linux систем, а также для MAC OS необходимо использовать другой менеджер пакетов. В Windows необходимо самостоятельно установить необходимое ПО или воспользоваться виртуальной машиной с Ubuntu (также можно использовать WSL версии не ниже 2).
Стандартный способ запуска демо предполагает наличие установленного пакета docker, а также docker-compose. Для автоматизации типовых операций используется утилита make, хотя можно обойтись и без неё, вручную выполняя соответствующие команды из файла Makefile в командной строке.
Другое используемое ПО (в Ubuntu будет установлено автоматически, см. следующий раздел):
- python (желательно версия не ниже 3.8)
- pipenv (для виртуальных окружений python)
Для работы с кодом примера рекомендуется использовать VS Code или PyCharm.
В случае использования VS Code следует установить расширения
- REST client
- Docker
- Python
Подразумевается наличие развернутой по предоставленному образцу машины с установленным и настроенным ПО, например, docker и docker-compose, с выбранным интерпретатором.
Для запуска примера рекомендуется использовать следующую комбинацию команд в терминалах 1 и 2:
1.1 docker-compose build --force-rm
1.2 make run (В устройстве начнут генерироваться и поступать сигналы от эмуляторов датчиков)
2.1 docker-compose logs -f --tail 100 (будет показан лог работы контейнеров)
1.3 make test (Будет запущен тестовый сценарий проверки работы основного функционала системы)
Можно пользоваться запросами из request.rest
1.4 docker stop $(docker ps -q) (завершение работы, альтернативно можно воспользоваться командами "turn_off" к "датчикам" через запросы в request.rest)
Система архитектруно выглядит следующим образом:
| Название | Назначение | Комментарий |
|---|---|---|
| scada | Эмулятор системы контроля и управления станции. Здесь - входная точка системы, которая принимает команды и запросы от оператора, позволяет авторизоваться и выдает подписанным пользователям данные, полученные от ПЛК. | - |
| license_server | Эмулятор сервиса, который проверяет возможность выполнения запрошенного действия (здесь - обновления) для заданного устройства и оператора. | - |
| plc | Непосредственно ПЛК, получает команды от операторов, выполняет их, обновляется по команде, принимает данные от датчиков (sensors), обрабатывает и передает их на СКАДУ. | - |
| sensors | Эмулятор датчиков, здесь их 3 - датчик температуры, мощности и количества оборотов турбины. Получают команды (старт/стоп/изменить пределы генерации), генерируют непосредственно данные раз в заданный промежуток времени и отдают их на ПЛК через HTTP. | Пределы генерации можно изменить через команды. (Команда -> scada -> plc -> sensors). Пример есть в тесте. |
| storage | Фактически это лишь папка с данными. Здесь она для простоты используется и scada и plc, хотя очевидно, что это разная память. Для подчеркивания разницы используются постфиксы _plc и _scada в названии файла. Файл version подразумевает "обновление", settings - настройки системы, используемые для сравнения в plc входных данных. Здесь же файл users - список ролей в системе и связанных с ними логинов и паролей. | Роли: Наблюдатель - может получать только данные. Оператор - может получать данные и менять настройки. Инженер - может обновлять ПО. |
Диаграмма последовательности выглядит следующим образом:
Cсылка на диаграмму для редактирования
В данном примере не используется брокер сообщений, взаимодействие между системами построено на базе REST запросов, однако в решении внутренние компоненты проектируемого устройства должны взаимодействовать через брокер сообщений (желательно Apache Kafka), внешнее взаимодействие следует по-прежнему через REST.
Пример такой реализации можно найти в репозитории https://github.com/sergey-sobolev/secure-update, подробное описание запуска примера есть на степике (https://stepik.org/course/133991/)
Хотя код этого примера написан на Python, команды могут по желанию своё решение сделать на других языках (C/C++, C#, Golang, Javascript/Typescript, Java, Rust, PHP), основные требования:
- использование брокера сообщений (предпочтительно Apache Kafka, но можно RabbitMQ, Mosquitto)
- наличие хотя бы одного функционального теста
- наличие тестов безопасности (предпочтительно автоматизированных, в крайнем случае - описание ручных тестов безопасности)
- наличие монитора безопасности, который должен контролировать все взаимодействия между доменами безопасности
- наличие политик безопасности, которые использует монитор безопасности. Политики безопасности должны обеспечивать реализацию предложенной политики архитектуры.
- Видео на youtube (записи занятий)
- Теория https://youtu.be/hTDBLP1Jlc0
- Разбор домашнего задания на проектирование; ключевые принципы и технологии работы кибериммунных систем https://youtu.be/eYr-toUUQDA
- Пошаговый разбор трансформации примера в новую систему https://youtu.be/BH2HrPltr7M
- Тестирование, в т.ч. тесты безопасности https://youtu.be/BEVZVm6xi-M
- Github wiki по теме со ссылками на примеры и решения на Python и Java https://github.com/sergey-sobolev/cyberimmune-systems/wiki/%D0%9A%D0%B8%D0%B1%D0%B5%D1%80%D0%B8%D0%BC%D0%BC%D1%83%D0%BD%D0%B8%D1%82%D0%B5%D1%82
- Заготовка описания решения команды https://github.com/sergey-sobolev/secure-update/blob/main/docs/report/report.md
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent