Security architecture

This page describes where Virtik's security controls are placed. It states the architecture as built, and says what has been tested and what has not. It is not a certification, an audit report or a promise.

The principle is that a control belongs as close to the data as it can be put. A control that lives only in the interface is a control a defect, a modified browser or another client can walk around. So the important ones are enforced in the database, beneath the application.

The layers#

Isolation between organisations

Tables that hold customer records are protected by row-level security, evaluated in the database against the signed-in user, and some of those tables also refuse to have that organisation changed once set; the guard is not on every table. The policies check the organisation a request names against the signed-in user's membership, with exceptions that are tracked.

Authorisation by role and by site

What a person may change is decided by their role, and where is decided by site access. Both are checked in the database.

Plan entitlement

Whether a capability is included in the organisation's plan is checked separately from the role. The database enforces it for some capabilities (site, seat and camera limits, patrol, AI and mobile). For others, such as Analytics, the application checks it in a separate call before reading.

Two-step verification

Administrators and editors are asked to enrol an authenticator app, and the database refuses some sensitive actions, such as changes to organisation settings, invitations and single sign-on, unless the session has completed two-step verification. This is not applied to every administrative action.

Sign-in protection

Passwords need at least 15 characters, and the sign-in form checks their strength. The sign-in page runs a proof-of-work check in the browser. The authentication service limits repeated failures per account, where its hooks are enabled. The browser signs a person out after two idle hours.

Audit

Many actions are recorded, and administrators with two-step verification can read a system trail of them. The audit record is not claimed to be tamper-evident or immutable.

Credentials

A camera's password, entered in the credential field, is held in a secure vault and is not returned to the browser.

AI governance

AI chat, retrieval and embedding requests pass through a gateway that applies the organisation's policy, mode, budget and approval rules. Vision analysis uses its own governance check. See AI governance.

Keeping the client untrusted#

Several rules exist because the client cannot be trusted:

• A row's organisation is protected from change after it is created on some of the tables that carry one. The guard is not on every table.
• Server-only helper functions are not callable by signed-in users. This was reviewed on local builds.
• Files are kept in a private storage bucket under policies tied to the owning organisation. Exceptions to these policies exist and are tracked.
• The application discards anything it loaded for one organisation when a person switches to another, so a slow response from the previous one cannot appear under the new.
• A person who is suspended, offboarded or past their access window stops being served data by the database's standard membership check, not only by the screen. A few older policies check less.

How it was tested#

Isolation, authorisation and several workflows have negative-control tests: a test that tries the forbidden thing, and a control that shows the test can fail. For example, another organisation's user calling 12 write routes for Digital Twin scenes, plans, hotspots, documents and annotations was refused on all of them, and the reads tried returned nothing; a tenant boundary test was shown to fail when the boundary was removed. Authentication was tested in a real browser on an isolated stack with the database built from source.

What has not been done#

Current availability#