Design Philosophy

Zonitix is single-tenant: each customer has a server and a database of their own. The product has two main parts: the Zonitix licensing server (the store), which every customer’s instance checks in with, and your instance, which we host for you alone.

One optional preview feature, Apple MDM, uses a third: a Zonitix-hosted service shared across customers.

What The Split Means For You

In a product where all customers share one database, a breach of that database exposes every customer at once. Here your business data sits in a database on an instance dedicated to you, and the store holds no passwords or credentials from your instance.

There is one exception, and only if you use it. Apple MDM (a preview feature) runs from one Zonitix-hosted service shared across customers, with each customer’s records in a separate tenant. If you enrol Macs in it, the management records for those Macs are held there and not on your server. What it holds is listed in the Trust Center sub-processor list; how your instance connects to it is under Technical detail below.

If something here is not working as you expect, start with When something goes wrong.

The backup destination in System → Backups & Recovery is an S3-compatible bucket or an Azure Blob Storage container that you own, and what is uploaded to it are database dumps. A failed heartbeat is written to the audit log as LICENSE_SYNC_FAILED; the entitlements already cached on the instance stay in force.

Request Routing Through The Gateway

Every request enters through one API gateway. It is the only service that accepts a session cookie or an API token; it checks the caller, applies rate limits, and passes a signed description of the caller to the internal service that does the work:

TLS ends at the network edge in front of your server. From there the request reaches the server through a tunnel the server opens outwards, and travels as plain HTTP between the containers on the instance’s own network. Every public host sends Strict-Transport-Security: max-age=31536000; includeSubDomains. The hop-by-hop path and the full header list are on Transport & Service Trust.

Trust Boundaries

• The gateway validates the session or the personal API token, then sets three headers on the forwarded request: x-user (a JSON description of the caller with the permission list), x-user-sig (a base64 Ed25519 signature over the exact bytes of that header, made with a per-instance private key) and x-internal-service-token (a JWT signed with HS256 using a per-instance secret, valid for 60 seconds). Any copy of these headers a client sends is deleted at the gateway before authentication.
• An internal service that holds the signing public key refuses a request whose x-user-sig is missing or wrong with 401 Identity signature invalid and records AUTHZ_XUSER_FORGED in the audit log. The full check order, and what happens when a key is not set, is on Transport & Service Trust.
• An internal service refuses a request that does not carry the internal service token with 401 Internal service trust failure (see API Error Troubleshooting). Calling a service directly, around the gateway, therefore fails.
• A personal API token never travels past the gateway: for a token-authenticated call the Authorization header is removed before the request is forwarded.
• A state-changing request that authenticates with the session cookie, and no Authorization header, must also carry an Origin (or Referer) the instance trusts; otherwise the gateway answers 403 CSRF check failed: missing or untrusted Origin. and records CSRF_REJECTED in the audit log. Calls that send an API token in the Authorization header are not subject to this check.

The Shared Apple MDM Service

Apple MDM (a preview feature) is the one part of the product that does not run on your server. It is a separate service that Zonitix hosts at mdm.zonitix.com, shared by all customers, with each customer’s records in a separate tenant. It is in the site’s sub-processor list in the Trust Center, which also names who hosts it. The Zonitix agent for macOS, Linux and Windows does not use this service; it reports to your own instance.

• How your instance registers. At each deploy, and again on first use if no key is stored, the instance sends one request to the service’s /provision address with your customer id (lower-cased; letters, digits, hyphen and underscore only) and, at deploy, your company name. The request is authenticated with a bearer token that belongs to your tenant alone, delivered to the server as a secret file.
• What comes back. A tenant API key. The instance stores it encrypted (AES-256-GCM) in its own settings and sends it as a bearer token on every later call. The browser never receives it.
• Registration does not wait for you to enrol a Mac. A server that holds a token registers at every deploy. If the server has no token, or the service cannot be reached, registration is skipped and tried again at the next deploy. The Apple MDM panel then shows that it is not connected and the Mac actions are not offered; nothing else on the instance is affected.
• What your instance sends to it. Requests an administrator makes on the device screens: read the list of enrolled Macs and their inventory, read the enrolment details, create an enrolment code, install or remove a configuration profile, install the agent together with a settings profile that holds your instance’s address and an enrolment token, lock, read the lock PIN set by a lock, restart or shut down, wipe, ask for security information and for the installed-app and certificate lists, and read a FileVault recovery key held there. It also uploads the Apple push certificate you provide.
• What it sends without an administrator. Every 15 minutes a background sync reads the enrolled-Mac list and collects any new FileVault recovery key held there. Where a FileVault profile is in use, it also asks a Mac with no key yet for its security information. While the server holds a token but no tenant key, each run also retries the registration.
• The push certificate’s private key is made on the service when you request a signing request, and kept there; you upload only the certificate Apple returns. An administrator with the destructive-device permission can download a backup of that key after a step-up.
• What the Macs send. A Mac enrols at an address the service supplies, not at your instance. The records the service holds as a result are listed in the sub-processor entry.
• Routine calls from your instance to the service are cut off after 5 seconds without an answer. A refusal of the tenant key is shown to the administrator as a 502, never as a sign-out.

The routes and permissions are on MDM & Device Operations.

Every other system your instance connects to, and when, is listed under Outbound connections on Transport & Service Trust.