Описание проекта

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

Разработка и Тестирование

Окружение для Разработки

Для работы с проектом убедитесь, что следующие инструменты установлены:

Docker

• Проверка: docker --version
• Установка: Docker

Docker Compose

• Проверка: docker-compose --version
• Установка: Включен в установку Docker

GNU Make

• Проверка: make --version
• Установка (Linux): sudo apt-get install make или sudo yum install make

Компилятор C++

• Linux: Обычно уже установлен или sudo apt-get install g++

• Windows: MinGW или компилятор Visual Studio

  Компилятор Rust

• Проверка: rustc --version

• Установка: Установка Rust
  • В Linux и macOS: Команда curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
  • В Windows: Скачайте и запустите rustup-init.exe

PowerShell (Windows)

• Установка: Уже предустановлен на Windows 10, для старых версий сайт Microsoft

Запуск сборки проекта:

make all

Остановка и очистка:

make clean

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

Тесты SecurityMonitor

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

Ожидаемые результаты тестов SecurityMonitor:

test_check_operation_valid: Успешно проходит для валидных комбинаций source, deliver_to и operation. Подтверждает, что функция правильно идентифицирует допустимые операции.

test_check_operation_invalid_source: Не проходит, если source недействительный или неизвестный. Демонстрирует, что функция отклоняет операции от недопустимых источников.

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

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

End-to-End Тесты

Для запуска end-to-end тестов в используется команда make tests. В Makefile определены разные скрипты для Windows (e2e-test.ps1) и Linux (e2e-test-a.sh, e2e-test-b.sh). Вы можете выбрать в Makefile нужный скрипт для запуска в зависимости от вашей операционной системы. Для запуска end-to-end тестов используйте команду: make tests

Ожидаемые Результаты End-to-End Тестов:

E2E Test A - Запуск аутентичной задачи A 1. Аналогичная проверка доступности сервиса FPS. 2. Запуск аутентичной задачи A. Ожидается подтверждение успешного запуска задачи. 3. Проверка логов FPS. Успех теста подтверждается наличием записи “Task A: started” в логах. Если запись не появляется в течение 60 секунд, тест считается неудачным.

E2E Test B - Попытка запуска неаутентичную задачу B 1. Проверка доступности сервиса FPS. Если сервис недоступен в течение 60 секунд, тест считается неудачным. 2. Запуск неаутентичной задачи B. Ожидается подтверждение успешного запуска задачи. 3. Проверка логов FPS. Успех теста подтверждается наличием записи “Task B: not authentic” в логах. Если запись не появляется в течение 60 секунд, тест считается неудачным.

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

1. Тушение возможно только в авторизованном районе.
2. Тушение возможно только авторизованным способом.

Полное описание компонентов:

1. Связь - получает полётное задание от Источника полетного задания.
2. Контроль обстановки - программно-аппаратные средства для оценки состояния пожарной обстановки в районе действия Огнеборца.
3. Управление перемещением - программно-аппаратные средства для перемещения дрона в заданную точку (на вход получает координаты, сам считает и выполняет перемещение).
4. Контроль уровня заряда батареи - проверяет остаточный уровень заряда аккумуляторной батареи, предоставляет информацию по запросу.
5. Навигация - теперь содержит две программно-аппаратные подсистемы - спутниковый навигационный приёмник и инерциальную навигационную систему (работает автономно), разработанные разными поставщиками.
6. Тушение водой - программно-аппаратные средства для тушения водой, для работы необходима дополнительная активация аппаратных цепей тушения.
7. Поджигание - программно-аппаратные средства для поджигания (запуска встречного пала), для работы необходима дополнительная активация аппаратных цепей поджига.
8. Контроль аутентичности полётного задания - программные средства, позволяющие достоверно проверить аутентичность полученного полётного задания.
9. Контроль активации цепей тушения и поджига - на основе полётного задания и текущих координат по запросу активирует необходимые аппаратные цепи, только этот компонент имеет возможность активации этих цепей, без которых тушение или поджиг невозможны. Работает непрерывно после успешной активации любой цепи, отключает цепи при нарушении условий активации.
10. Комплексирование - программный компонент, непрерывно анализирует информацию от двух источников навигационных данных, алгоритмы системы комплексирования позволяют обнаружить нарушение целостности навигационных данных.

Описание сценариев нарушения целей безопасности

+ отмечены доверенные компоненты

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

НС-1

Связь получила изменённое полётное задание, что привело к нарушению ЦБ1 и ЦБ2.

НС-2

Комплексирование неверно вычислило текущее местонахождение БПЛА, что привело к нарушению ЦБ1.

НС-3

Контроль активации цепей тушения и поджига скомпрометирован, что привело к нарушению ЦБ1 и ЦБ2.

НС-4

Управление перемещением скомпрометировано, что привело к ошибке в расчете координат, что привело к нарушению ЦБ1.

НС-5

Тушение водой скомпрометировано, что привело к нарушению ЦБ1 и ЦБ2.

НС-6

Поджигание скомпрометировано, что привело к нарушению ЦБ1 и ЦБ2.

НС-7

Контроль аутентичности полётного задания скомпрометирован, что привело к неспособности распознать поддельное или измененное полетное задание и нарушению ЦБ1.

Схема с указанием доверенных компонентов

Доверенные компоненты

Качественная оценка доменов

Качественные оценки доменов:

• оценка сложности кодовой базы:
  • c — complex (сложный);
  • m — medium (средней сложности);
  • s — simple (простой);
• оценка объёма кодовой базы:
  • S — small (малый);
  • M — medium (среднего объёма);
  • L — large (большой);
  • XL — extra large (огромный).

Проверка негативных сценариев

Сопоставление компонент с кодом

В компонент Связь входят компоненты FPS (Flight Processing System) и Connection. Они выполняют следующие функции:

• FPS (Flight Processing System): отвечает за обработку задач, связанных с полетами. В его задачи входит отслеживание полетных заданий.

• Connection: действует как интерфейс связи в системе. Он может ответственный за управление подключениями между различными системами, обработку передачи данных и обеспечение надежной связи между внешним источником полётных задач и системой.

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

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

Типы заданий для монитора безопасности

1. Пуск процедуры тушения в районе А.
2. Запрос текущих координат и получение координат от комплексирования.
3. Команда перемещения в район А.
4. Получение сигнала о завершении перемещения.
5. Команда тушения/поджига.
6. Запрос и получение ответа от контроля обстановки о запуске процедуры тушения/поджига.
7. Команда о завершении алгоритма тушения.
8. Контроль целостности координат и отправка ответа с координатами.
9. Приём запроса на координаты от комплексирования и отправка координат.
10. Обработка запроса на проверку запущен ли алгоритм тушения и отправка ответа.
11. Команда на активацию цепей тушения и поджига.
12. Информация об остановке тушения или поджига.
13. Запрос на контроль уровня заряда батареи и отправка информации.