Обновить KIBATS_SVETOFOR/README.md
This commit is contained in:
@@ -4,3 +4,47 @@
|
|||||||
> Ссылка на файлы
|
> Ссылка на файлы
|
||||||
> https://disk.yandex.ru/d/hRNTxnsgCIw-iA
|
> https://disk.yandex.ru/d/hRNTxnsgCIw-iA
|
||||||
***
|
***
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
### Региональный этап Чемпионата высоких технологий – «Конструктивная информационная безопасность автономных транспортных систем» (КИБАТС)
|
||||||
|
|
||||||
|
**Длительность:** 15 ч (4 модуля по 4, 4, 3, 4 ч).
|
||||||
|
**Среда:** Jupyter Notebook, тестирование в симуляторе (без робота).
|
||||||
|
|
||||||
|
#### Модуль А (4 ч) – Кибериммунная архитектура (светофор)
|
||||||
|
- **Задания:** сформулировать ЦБ и ПБ, реализовать классы `Event`, `Monitor`, `ControlSystem`, `LightsGPIO`, заполнить `ALLOWED_STATES`.
|
||||||
|
- **Рекомендации:**
|
||||||
|
- ЦБ должны быть чёткими (субъект, действие, объект), минимум 2. ПБ – минимум 2, описывают доверенные компоненты.
|
||||||
|
- `ALLOWED_STATES` – список словарей с полями `car_green`, `ped_green` и др. Исключите одновременное включение зелёного для машин и пешеходов.
|
||||||
|
- `Monitor` должен быть единственной точкой, через которую проходят все команды. `ControlSystem` отправляет события в очередь монитора, а не напрямую в `LightsGPIO`.
|
||||||
|
- Архитектурная диаграмма должна отражать поток: ControlSystem → Monitor → LightsGPIO.
|
||||||
|
|
||||||
|
#### Модуль Б (4 ч) – Монитор безопасности (3 политики)
|
||||||
|
- **Политика Б.1 (whitelist):** проверяет, что `params` события входят в `ALLOWED_STATES`. Иначе – блокировка.
|
||||||
|
- **Политика Б.2 (логирование):** при нарушении записывает `timestamp`, `source`, `operation`, `params`.
|
||||||
|
- **Политика Б.3 (rate limiting):** не более 5 событий/сек от одного источника; при 14 из 20 – блокировка источника.
|
||||||
|
- **Рекомендации:**
|
||||||
|
- Реализуйте каждую политику как отдельную функцию, зарегистрированную в мониторе.
|
||||||
|
- Используйте `datetime.now()` для `timestamp`.
|
||||||
|
- Для rate limiting – храните очередь времени событий по каждому источнику.
|
||||||
|
|
||||||
|
#### Модуль В (3 ч) – Нейтрализация киберпрепятствий (CybTL_01–04)
|
||||||
|
- **CybTL_01** – инъекция запрещённого состояния (проверка через whitelist).
|
||||||
|
- **CybTL_02** – подмена источника (проверка по списку доверенных источников).
|
||||||
|
- **CybTL_03** – DoS-флуд (rate limiting по источнику).
|
||||||
|
- **CybTL_04** – Replay-атака (проверка `timestamp` – отклонять события старше 1 секунды).
|
||||||
|
- **Рекомендации:**
|
||||||
|
- Все защиты должны быть реализованы в мониторе (как политики или отдельные методы).
|
||||||
|
- Тесты (готовые ячейки) должны проходить без ошибок.
|
||||||
|
|
||||||
|
#### Модуль Г (4 ч, вариатив) – Интеграция с внешними системами
|
||||||
|
- **Задания:** реализовать класс `CitySystemConnector` с методами `get_command_from_city()` и `send_command_to_monitor()`, добавить политику авторизации в монитор (команда проходит только при `from_city=True` и `authorized=True`).
|
||||||
|
- **Рекомендации:**
|
||||||
|
- `send_command_to_monitor()` должен создавать `Event` с флагом `from_city` и отправлять его в очередь монитора.
|
||||||
|
- Политика авторизации должна проверять оба флага. Не допускайте прямого вызова `LightsGPIO` из коннектора.
|
||||||
|
- Тесты (модуль Г) должны подтверждать, что неавторизованные команды отклоняются.
|
||||||
|
|
||||||
|
|
||||||
|
|||||||
Reference in New Issue
Block a user