Security профили для production

Security final pass (v0.54.0): operator checklist docs/features/encryption/security-final-checklist.md; threat model refresh docs/features/encryption/security-threat-model.md.

Техническая модель угроз и поверхности атаки: security-threat-model.md.

0.17-fix.x: security foundation

Ошибки API — детали ошибок и чувствительные поля в JSON не раскрываются без необходимости (см. обработчики API и redaction).
Webhook — тело запроса всегда проходит redact.RedactAny; политика policy.* управляет включением snapshot/manifest/paths/labels (см. docs/features/observability/webhooks.md).
Публичный API артефактов — path/object key по умолчанию с basename-redaction, если не включён ExportPolicy.IncludePaths на агенте (docs/reference/job-format-v1.md).
Metadata export / support bundle — redaction и export policy; не смешивать с полями YAML job.
Snapshots — executed_job_snapshot в run хранится sanitized (без значений секретов).
Манифест — не должен содержать секретных значений; см. docs/reference/manifest-schema.md.
Capabilities / facts / health — без секретов и без «глубоких» сетевых probe к внешним системам; только registry + локальные факты (docs/reference/capabilities.md).
Права на *_path файлы (токены, ключи) — операционный hardening; агент отклоняет group/world-readable секретные файлы (internal/fsperm, internal/agent/dependencies.go). Полная матрица edge cases — см. docs/features/encryption/security-final-checklist.md.
Шифрование payload backup на клиенте — streaming + optional envelope behind features.encryption / features.envelope_encryption (docs/features/encryption/encryption.md, internal/encryption); ключи только через refs, не inline в git.

Ниже — готовые минимальные профили запуска iobackup-agent для разных контуров.

Профиль 1: internal-only

Для приватной сети/VPN, когда агент доступен только из trusted-сегмента.

Рекомендуется:

bind на приватный адрес;
включить Bearer auth;
включить rate limit;
закрыть порт firewall-правилами.

Пример запуска:

export IOBACKUP_API_TOKEN="change_me"

./iobackup-agent \
  -listen 10.10.0.12:8735 \
  -auth-enabled \
  -auth-token-env IOBACKUP_API_TOKEN \
  -auth-allow-metrics-unauth=false \
  -rate-limit-enabled \
  -rate-limit-rps 20 \
  -rate-limit-burst 40 \
  -rate-limit-by-ip=true

Профиль 2: public-api

Когда API доступен извне через reverse proxy / ingress.

Рекомендуется:

HTTPS (TLS) на агенте или на edge proxy;
Bearer auth обязательно;
строгий rate limit;
allowlist IP или WAF на perimeter;
/metrics — только через auth.

Пример запуска (TLS на агенте):

export IOBACKUP_API_TOKEN="change_me"

./iobackup-agent \
  -listen 0.0.0.0:8735 \
  -tls-cert-file /etc/iobackup/tls/server.crt \
  -tls-key-file /etc/iobackup/tls/server.key \
  -auth-enabled \
  -auth-token-env IOBACKUP_API_TOKEN \
  -auth-allow-metrics-unauth=false \
  -rate-limit-enabled \
  -rate-limit-rps 10 \
  -rate-limit-burst 20 \
  -rate-limit-by-ip=true

Профиль 3: strict-mtls

Для высокозащищенного контура (service-to-service), где каждый клиент имеет свой сертификат.

Рекомендуется:

mTLS (client cert required);
Bearer auth как второй фактор доступа;
очень ограниченный список клиентов по client CA;
отдельный CA для клиентов iobackup.

Пример запуска:

export IOBACKUP_API_TOKEN="change_me"

./iobackup-agent \
  -listen 10.10.0.12:8735 \
  -tls-cert-file /etc/iobackup/tls/server.crt \
  -tls-key-file /etc/iobackup/tls/server.key \
  -tls-client-ca-file /etc/iobackup/tls/clients-ca.crt \
  -auth-enabled \
  -auth-token-env IOBACKUP_API_TOKEN \
  -auth-allow-metrics-unauth=false \
  -rate-limit-enabled \
  -rate-limit-rps 15 \
  -rate-limit-burst 30 \
  -rate-limit-by-ip=true

Минимальный чек-лист hardening

Токены не хранить в CLI history, только через env/file.
Ротация IOBACKUP_API_TOKEN по регламенту.
Приватные ключи TLS: права 600, владелец service user.
Ограничить исходящие подключения агента (egress policy).
Логи и agent.db хранить на защищенном диске/разделе.
Регулярно проверять 401/429 и failed webhook/backup метрики.