Hardening checklist¶

Before going productive, walk through this list. Everything is optional, but you shouldn't skip most of it. Agents and collectors always connect to the server on their own; no inbound port has to be open on monitored machines. Only the active collector on the Vesana server opens connections to the targets of its checks itself. The points below harden the server itself.

Authentication¶

[ ] Mandatory 2FA for super admins and admins via a rule under Admin → Login & Security → 2FA & Sessions — methods: authenticator app (TOTP) or passkey/hardware key (WebAuthn). Backup codes are created on setup. See 2FA.
[ ] Session lifetime reviewed — default 30 days without use, at most 90 days; “Stay signed in” can be forbidden (Login sessions)
[ ] First admin account (from the setup wizard) with a strong password and 2FA — and not used for everyday work
[ ] Login rate limit in effect — 10 requests/min per client IP for login and 2FA verification; 5 wrong 2FA codes lock the account for 30 minutes
[ ] Behind your own reverse proxy: add its address under Admin → Login & Security → Admin Access → Advanced as a trusted proxy, otherwise the session list and audit log show the proxy's address
[ ] Restrict the admin area (optional): IP allowlist or a dedicated admin container under Admin Access — see Admin access & split container

Tokens¶

[ ] Agent tokens only on the machine they were issued for — a token is valid for exactly one host
[ ] Renew lost tokens/keys immediately (Manage host → Renew token, or Regenerate Key on the collector) — see Tokens & API keys
[ ] .env protected — mode 600 (set by the installer); it contains SECRET_KEY, FIELD_ENCRYPTION_KEY and the database passwords

Encryption¶

[ ] FIELD_ENCRYPTION_KEY in password manager + printed backup in safe
[ ] Key backup separate from DB backup
[ ] Only 1–2 people should know the key

TLS¶

[ ] Real cert (Let's Encrypt or own CA), not self-signed in production
[ ] HSTS active (default)
[ ] TLS 1.2/1.3 — default in the built-in nginx; set it there if you run your own reverse proxy
[ ] Automatic renewal (certificate from Vesana) or put the “TLS Certificate” check on the “Vesana Server” host into an alert rule

Network¶

[ ] Outbound allowlist on the server: only allowed targets (container registry, licence portal, Vesana library community.vesana.org if used, browser push services, SMTP, notification services) — see Privacy & outbound connections
[ ] Inbound only 80/443 (or the ports you chose) — all other ports closed except possibly SSH. If agents report in from other networks: enable the agent gateway and expose ONLY the gateway port publicly (UI port internal/VPN)
[ ] SSH key-only, no password
[ ] Fail2ban or similar for SSH brute force
[ ] Firewall rules documented and versioned

Redis¶

[ ] Redis password set (REDIS_PASSWORD in the .env — generated by the installer)

Container isolation¶

[ ] Confirm non-root — API, worker, receiver and AI-service containers run as non-root (USER app, UID 1000). The one deliberate exception: the updater container stays root because it has to write to the Docker socket to apply updates.
[ ] Docker socket not additionally mounted into other containers
[ ] Web server container (nginx) — the worker processes run as the nginx user, no change needed

Logging and monitoring¶

[ ] Audit log retention reviewed (Admin → System → Resources → Storage; default: unlimited)
[ ] External log tailing if compliance-relevant (e.g. to SIEM)
[ ] Checks on the “Vesana Server” host included in an alert rule — they report problems of the instance itself
[ ] Failed logins on monitored machines reported via an event log/script check + alert rule

Updates¶

[ ] GUI updater works (test with a small update before the first live update)
[ ] Security updates automatic — Admin → System → Updates (default for new installations)
[ ] Backup before every update runs (default)
[ ] Update window communicated (status page / wiki)

Backup¶

[ ] Automatic backups scheduled (Admin → System → Backup & DR)
[ ] Off-site copy (at least weekly)
[ ] Restore drill at least once a quarter
[ ] .env backup separate

RBAC¶

Vesana grants rights through roles: four built-in ones (Super Admin, Admin, Operator, Viewer) plus custom roles with freely assembled permissions. A role applies per tenant — an account (or a team) can be admin in one tenant and read-only in another. What an account may not do in a tenant, the server refuses (403); data of other tenants it doesn't see at all. Details: Roles & permissions.

[ ] Permission inventory — no user with more than needed
[ ] Super admin for few accounts only — super admins see all tenants and are exempt from restrictions
[ ] Auditor role for external auditors (read-only permissions like audit_log.view_tenant)
[ ] “All tenants” assignments only where really needed (MSP roles)

AI¶

[ ] If cloud provider: be clear about what goes to the API
[ ] AI permissions sparingly — not every user needs ai.query/ai.analyze
[ ] AI web search: if the wiki returns too little, the question goes to DuckDuckGo — also with local Ollama (see Privacy)

Smartphone / push¶

[ ] HTTPS is mandatory — without a secure context no browser allows installation or push
[ ] Back up the push keys (VAPID) — they belong to the instance and are part of the backup; after a rebuild without a backup every device has to re-enable push

Custom code (scripts, profiles)¶

Script-capable check types (agent_script, agent_custom, ssh_script, ssh_custom, ssh_command, api_script, plugin_local) can run arbitrary code on monitored machines or on the collector — the most sensitive point in the whole system, and therefore secured separately:

Apply scope per user: who may create/change script checks can be restricted granularly — by tenant, by tag or to individual hosts. Without an own setting the role default applies: Admin may apply scripts on all reachable tenants, every other role may not (super admins are never restricted). A saved setting replaces the default — including “None” for an admin.
Reach is asked, not assumed: before saving script content, Vesana shows how many checks use it — you choose “for all”, “as own script” (copy) or “this device only”. So nobody accidentally changes a script shared by many hosts.
Confirm identity: whoever changes executed code (create a script, change its body, import a bundle with code) confirms their identity again — on by default, can be turned off under Admin → Login & Security → 2FA & Sessions.
Active collector: runs as its own service account with restricted rights, not as root. Server-internal addresses (loopback, Docker networks) are blocked for checks not saved by a super admin, and per tenant you can allow whether checks or own plugins may run via the server (Admin → Agents & Collectors → Active checker).
Agent Lock: on the host itself you can require that scripts only run after local approval — protection in case Vesana itself is compromised. See Agent Lock.

Checklist:

[ ] monitoring_scripts.create/.edit not for viewer/operator
[ ] Apply scope per user restricted sensibly (not blanket “all tenants”)
[ ] Custom scripts tested on a test machine before rollout
[ ] Profile imports from unknown sources with care

Security updates¶

[ ] CVE feeds watched (Postgres, Redis, FastAPI, React)
[ ] Apply updates promptly (GUI updater, automatic security updates)

Operations documentation¶

[ ] Runbooks in wiki — what to do on XYZ
[ ] Contact list for escalation (in wiki)
[ ] Status page for external comms
[ ] FIELD_ENCRYPTION_KEY storage documented (who has access)

Compliance-specific¶

Standard	What specifically
ISO 27001	Audit log + 2FA + backup drill sufficient for most audits
GDPR	Vesana monitors devices, not people — but logs and user accounts can contain personal data, see Privacy
HIPAA	Disable cloud AI or choose a provider with a BAA
PCI	Vesana is out of scope if not in the card-data path — but can help with monitoring