Чек-лист усиления безопасности аппаратной платформы (Appliance Hardening)¶

Документ описывает обязательные и рекомендуемые меры усиления безопасности (hardening) при развёртывании Iris VMS как поставляемого устройства (HW + SW) на площадке клиента. Каждый пункт сопровождается обоснованием. Чек-лист охватывает уровень хоста/ОС, сетевую сегментацию, уже встроенное усиление контейнеров и меры на уровне приложения.

Iris VMS — это on-prem система видеонаблюдения с ИИ: один GPU класса NVIDIA T4/L4 (16 ГБ), два Docker-контейнера (vms — FastAPI API + подпроцессы-воркеры на камеру; vms-scanner — изолированный сервис обнаружения/аудита), SPA на vanilla-JS без сборки, SQLite (WAL) как единственный источник истины. Среда выполнения уже способна работать в air-gap (модели кэшируются локально, SPA самодостаточна, телеметрии и «звонков домой» нет).

1. Шифрование данных на диске (LUKS) — ПЕРВИЧНЫЙ контроль at-rest¶

[ ] Включить LUKS full-disk encryption на системном/данных-диске. Это основной механизм защиты данных в покое. Он защищает базу SQLite, локально закэшированные модели (интеллектуальная собственность), а также биометрические артефакты (лица, идентичности). При краже или изъятии устройства диск нечитаем без ключа.
[ ] Хранить ключ дешифрования вне устройства (passphrase при загрузке, TPM-unseal с PIN или внешний носитель). Не оставлять keyfile в открытом виде на незашифрованном разделе.
[ ] Рассматривать LUKS как защиту от физического доступа, а не от скомпрометированной работающей системы: после разблокировки данные доступны процессам. Поэтому LUKS дополняется (а не заменяется) шифрованием секретов на уровне приложения (см. раздел 7).

2. Secure Boot и целостность загрузки¶

[ ] Включить UEFI Secure Boot. Гарантирует, что загружаются только подписанные загрузчик и ядро, что препятствует подмене на скомпрометированный загрузочный образ (evil-maid).
[ ] Защитить настройки UEFI/BIOS паролем и отключить загрузку с внешних носителей, чтобы исключить обход с live-USB.

3. SSH: отключить или только по ключу¶

[ ] Отключить SSH полностью, если удалённое администрирование не требуется. Минимизирует поверхность атаки.
[ ] Если SSH необходим — только аутентификация по ключу (PasswordAuthentication no), запрет root-логина (PermitRootLogin no), доступ ограничен доверенной управляющей сетью. Обоснование: пароли подвержены перебору; ключи и сетевое ограничение резко сужают вектор удалённой компрометации.

4. Хост-файрвол: наружу только 443¶

[ ] Открыть наружу только TCP/443 (HTTPS через nginx). Всё остальное закрыть по умолчанию (default-deny).
[ ] Сам контейнер vms уже слушает только loopback 127.0.0.1:8120; внешний доступ терминируется nginx с TLS. Файрвол хоста закрепляет это на уровне ОС, чтобы случайно открытый порт не стал точкой входа.
[ ] Исходящие соединения ограничить по принципу наименьших привилегий. В air-gap/offline-режиме исходящий интернет-трафик не требуется (см. раздел 9).

5. Сегментация сети камер (VLAN / отдельный NIC)¶

[ ] Изолировать камеры в выделенном VLAN или на отдельном физическом NIC. IP-камеры — частый источник уязвимостей (слабые/зашитые пароли, устаревшие прошивки). Сегментация не даёт скомпрометированной камере достичь корпоративной сети или управляющего интерфейса.
[ ] Запретить камерам выход в интернет; разрешить только трафик RTSP/ONVIF между камерами и устройством Iris.
[ ] Учитывать, что Iris включает встроенный аудит безопасности камер (RTSP/ONVIF/Dahua/Hikvision/XM) — используйте его для инвентаризации и выявления слабых мест в сегменте камер.

6. Автоматические обновления безопасности¶

[ ] Включить автоматическую установку обновлений безопасности ОС (например, unattended-upgrades или эквивалент). Своевременное закрытие уязвимостей ядра и системных пакетов снижает окно атаки.
[ ] Поддерживать в актуальном состоянии драйвер хоста (CUDA 12.4) и NVIDIA Container Toolkit — это предпосылки работы GPU; обновлять в контролируемом окне обслуживания, чтобы не нарушить совместимость.

7. Усиление контейнеров (уже реализовано)¶

Эти меры уже встроены в поставку — задача при развёртывании их проверить и не ослабить:

[ ] Контейнер работает не от root (uid 1000).
[ ] cap_drop: [ALL] — сброшены все Linux capabilities.
[ ] no-new-privileges — запрет повышения привилегий.
[ ] Read-only монтирование исходного кода — контейнер никогда не пишет в собственный исходник; все записи идут в data/.
[ ] Привязка к loopback 127.0.0.1:8120 за nginx. Обоснование: даже при компрометации приложения «взрывной радиус» ограничен непривилегированным процессом без capabilities и без права на запись своего кода.

8. Шифрование секретов на уровне приложения¶

[ ] Секретные поля шифруются в покое через app/crypto.py (например, cameras.onvif_password). Схема: stdlib HMAC-CTR, encrypt-then-MAC.
[ ] Ключ берётся из IRIS_SECRET_KEY (env) или из data/secret.key (права 0600) и никогда не хранится в БД.
[ ] Обеспечить наличие и защиту ключа при развёртывании; потеря ключа делает зашифрованные секреты невосстановимыми. Обоснование: это дополнительный слой поверх LUKS — защищает учётные данные камер от чтения процессами/дампами БД уже после разблокировки диска. LUKS остаётся первичным контролем at-rest.

9. Offline / air-gap режим¶

[ ] Включить настройку offline_mode, чтобы отключить единственные функции, обращающиеся в публичный интернет: поиск камер через Shodan и ingest веб-ссылок через yt-dlp.
[ ] Для офлайн-инференса выставить HF_HUB_OFFLINE=1 и TRANSFORMERS_OFFLINE=1 (MiVOLO age/gender уже учитывает local_files_only).
[ ] Опциональные ИИ-сайдкары размещаются в LAN и работают по принципу fail-open: STT whisper-xtts (:8000), перевод ollama+EuroLLM (:11434), дубляж xtts, mediamtx для browser-cam. Убедиться, что они доступны только из доверенного сегмента.
[ ] Бэкапы (scripts/backup_*.sh через rclone) перенаправить на on-prem MinIO через S3_ENDPOINT — данные не покидают площадку.

10. Аутентификация и аудит действий администратора¶

[ ] Учитывать текущую модель auth: приложение доверяет заголовку SSO X-Email (встроенного логина/ролей пока нет — это запланированный пункт WS2). До его появления аутентификацию и контроль доступа обеспечивает внешний слой (nginx SSO) — он должен быть корректно настроен и защищён.
[ ] Журналирование действий администратора — запланировано (planned). До внедрения полагаться на логи nginx/обратного прокси и логи хоста для трассировки административных действий.

11. Физическая безопасность¶

[ ] Размещать устройство в запираемом помещении/стойке с ограниченным доступом. Физический доступ нивелирует многие программные меры.
[ ] Заблокировать/опломбировать порты и слоты (USB, консоль), где это применимо, чтобы исключить локальный обход.
[ ] Сочетание физического ограничения доступа, защиты UEFI (раздел 2) и LUKS (раздел 1) образует целостную защиту от атак с физическим доступом.

Примечание о лицензиях моделей (release-gate, отложено)¶

Не является мерой hardening, но должно учитываться при поставке: модели имеют ограничительные лицензии — YOLOv8 (AGPL), InsightFace buffalo_l (non-commercial), OSNet/MSMT17 (research-only). Поскольку устройство поставляется on-prem, это худший случай по лицензионным рискам. Remediation отложена (accepted risk); путь устранения описан в docs/LICENSING.md (переход на RTMDet/RT-DETR + DINOv2; лицензирование или отсрочка face-модуля).