SECURITY MODEL · DRAFT

Надёжность должна быть доказуема

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

Ниже — целевая модель, а не заявление о пройденном аудите. До промышленного запуска нельзя обещать сертификацию, ГОСТ-шифрование или гарантированный SLA без подтверждающих испытаний и документов.

1. Доступ и аудит

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

2. Гоночные события

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

3. Offline-first

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

4. Защита и восстановление

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

5. Проверка перед релизом

Threat model, тесты разграничения ролей, имитация потери сети и дублей, восстановление из резервной копии, нагрузочный тест live-ленты и независимый аудит критических путей.