Vizno · Compliance
Zero-Trust Access Architecture
How Vizno's production access posture implements zero-trust principles - no implicit network trust, explicit identity per request, least privilege, continuous verification.
1. Purpose
This document describes how the Vizno production environment implements zero-trust access principles. Zero trust, as applied here, means four things: no implicit network trust (being inside a private network does not by itself authorize access); explicit identity per request (every request is authenticated to a specific identity the receiving system independently verifies); least privilege (each identity is granted only the minimum access required for its role); and continuous verification (privileged sessions re-prove identity periodically rather than relying on a long-lived token). Sections 3-6 detail each.
3. Network surface
- No public database listener. The PostgreSQL database is not exposed to the public internet on any address. The TCP listener is bound only to the internal Docker bridge network on the Hetzner host.
- Tailnet-only operator access. Operator workstations reach the database (and other internal services) over the Tailscale tailnet. The Hetzner host is a tailnet subnet router advertising the internal Docker network range. A device that is not a member of the tailnet has no network path to the database.
- Edge proxy in front of the application. All public web traffic transits Cloudflare's edge, which provides DDoS protection, Web Application Firewall rules, and TLS termination. The Hetzner origin accepts inbound web traffic only on the edge-facing port.
4. Identity per request
- Operator identity at the network layer. Tailscale device identity is bound to a named user account and a device key. There are no shared device keys. A revoked device key cannot reconnect to the tailnet.
- Operator identity at the system layer. SSH to the Hetzner host requires an authorized SSH key tied to a named user; password authentication is disabled. There is no shared root password.
- User identity at the application layer. End-user requests are authenticated by Better Auth, which validates a server-side session record on every request. There is no client-side token that the server trusts without verification.
- Webhook identity. Inbound webhooks (Plaid, Increase, Resend, Modal, RunPod) are verified against the provider's signing secret using a timing-safe HMAC comparison before the payload is parsed. Unverified webhooks are rejected with no side effects.
5. Least privilege
- Application admin role is separate from sign-in role. Reaching the admin surface requires the application user to hold
profiles.role = 'admin', which is granted explicitly by the founder. A general signed-in user cannot reach/adminregardless of session state. - Service-to-service credentials are scoped. API keys to third-party services (Anthropic, Resend, Plaid, Increase, Payoneer, Cloudflare R2) are scoped to the minimum permissions required and are kept in the Coolify secrets store, not in source control.
- Database access is role-bounded. The application connects to PostgreSQL as a database role that owns its tables. Migration runs as a privileged role; the runtime role is granted no DDL.
6. Continuous verification
- Application MFA on every sign-in. Elevated-role sessions (admin, affiliate, creator) require email-based one-time-code verification on every newly created session before the session can reach any protected destination. See the email MFA implementation summary in the security policy.
- Session expiry. Application sessions expire after 30 days and are refreshed when an active session is older than 1 day. Long-lived sessions that are never re-validated are not used.
- Audit logging of privileged actions. Administrative actions in the application (role grants, content moderation, payouts) are written to an append-only audit log. The log includes the operator identity, the action, the affected resource, and the timestamp.
8. What zero-trust does not mean here
Vizno's posture does not require user devices to enroll in a corporate device-management product to reach the application; end users access the platform over the public internet from arbitrary devices, with identity verified at the application layer.
The zero-trust principles above apply to production access (operator access to infrastructure, and elevated-role access to the application admin surface). End-user posture is governed separately by the privacy policy, security policy, and applicable law.
9. Policy review
This document is reviewed at least annually by the founder and updated as the production architecture evolves. Specific implementation references (vendor names, version numbers) are kept current with the actual state of the platform.
10. Contact
Questions about this architecture document or its implementation: security@vizno.com.