Security & Compliance
This page describes the platform's trust boundaries and the controls that enforce them: how an on-prem Ozone Data Collector proves its identity to the Ozone Orchestrator, how one tenant's data is kept separate from another's, what is encrypted where, and how identity and access are managed. It is written for customers evaluating the platform and for administrators preparing a compliance review.
The platform minimises trust at the boundary: raw device credentials and the full telemetry firehose stay on the customer's premises, and the cloud authenticates every collector with a signed token rather than trusting the network.
1. Collector authentication
The collector-to-cloud channel is always an outbound HTTPS connection initiated by the collector and secured with TLS. The cloud never dials in to the appliance, and the collector holds no listening ports that face the internet. Each collector authenticates with a signed bearer token plus an unguessable ingest token, so a leaked network session alone can never impersonate a collector.
Three credentials cross the boundary for telemetry sync, each with a distinct purpose:
| Credential | Purpose | Lifetime | Protection |
|---|---|---|---|
| Registration token | One-time enrolment of a new collector | 72 hours, single-use | Long random value, stored only as a salted hash at rest, consumed on first successful registration |
| Collector identity token | Proves the collector's identity on every heartbeat and sync | Long-lived, re-issued on re-registration | Signed by the cloud; carries the collector and tenant identity; revoked by removing the collector in fleet view |
| Ingest token | Routes forwarded telemetry to the correct tenant | Valid until rotated | Resolved to a tenant at the gateway; an unknown token is rejected |
Payload protection is layered on top of the transport. Forwarded data is compressed by default, and on the Enterprise tier it is additionally encrypted at the payload layer (AES with an HMAC integrity check) using a key that the customer injects as a secret and that is never baked into the appliance image. That second layer stays in force independently of TLS, so the contents are protected even if a transport session is compromised.
1.1 Offline operation and identity
A collector is designed to keep running when the cloud is unreachable. It verifies its license and enforces its entitlement tier locally, so it continues to collect and operate during a WAN outage. For human access, the on-prem console can verify an operator's identity offline by validating a short-lived, signed identity token against public keys it has cached from the cloud, with no round-trip required. This lets a signed-in operator keep working through an outage while all sign-in material stays cryptographically verifiable and scoped to the local appliance. An offline session can never mint a cloud session, so the blast radius of any offline access stays local.
2. Multi-tenant isolation
Tenant separation is enforced at four independent layers. A missing tenant filter at any one layer is treated as a top-severity security defect.
| Layer | Mechanism |
|---|---|
| Identity | tenant_id is a signed token claim; a collector cannot assert another tenant |
| Quota | A per-tenant rate limiter drops over-limit traffic rather than letting one tenant crowd out another |
| Bus | Telemetry is published to tenant-scoped subjects on the internal message bus |
| Storage | Analytics storage is physically partitioned by tenant, and every relational table and metric series carries the tenant identifier |
Because analytics storage is partitioned physically by tenant, a query for one tenant never reads another tenant's data off disk, so isolation and query performance come from the same design.
3. Encryption
| State | Control | Notes |
|---|---|---|
| In transit (boundary) | TLS 1.2+ on all collector-to-cloud HTTPS, terminated at a managed CA certificate | Production uses a real CA certificate, never a self-signed one |
| In transit (payload) | Optional payload encryption (AES with HMAC integrity) on Enterprise ingest | Independent of TLS; key injected as a secret |
| In transit (internal) | Service-to-service traffic runs on a private network and is not exposed publicly | The gateway is the only front door |
| At rest | Disk and volume encryption on the host (LUKS on-prem, KMS-backed volumes in cloud) | Applied at the volume layer beneath the databases |
| Secrets | Injected at runtime, never baked into the appliance image or committed to source | See section 5 |
The public ingestion endpoint is held to a modern TLS floor: TLS 1.2 and 1.3 only, strong cipher suites, and HTTP Strict Transport Security with related response-hardening headers.
4. Authentication, IAM & RBAC
Human identity is brokered by Keycloak, a standards-based identity provider. It supports multi-factor authentication and single sign-on via OIDC, so customers can federate the portal with their existing identity provider and enforce MFA centrally. Collector identity is the signed token from section 1, a non-human principal that is never a Keycloak user.
Secrets and default credentials are never shipped in a production configuration. A deployment that still serves a development default fails its own security review, so all default credentials must be rotated before the portal is exposed.
Role model. The platform defines five roles, checked at the gateway and again in each service:
| Role | What it can do |
|---|---|
| SuperAdmin | Full platform control across every tenant (operator plane) |
| TenantAdmin | Full control within one tenant: users, collectors, billing, integrations |
| Engineer | Day-to-day operations: acknowledge and act on alerts, problems, and remediation within the tenant |
| ReadOnly | View-only access to dashboards and data; no mutating actions |
| Auditor | View-only access aimed at compliance review, including audit trails |
tenant_id is a signed token claim, so a role is always scoped to its own tenant. Only SuperAdmin crosses that line. The on-prem collector console mirrors this model on a smaller scale, deriving the operator's role from the signed token to gate console actions.
5. Audit logging
Every configuration change on the collector is recorded in an append-only audit log. Each entry captures the timestamp, the acting operator, the action, the target, and the source, covering events such as connecting or disconnecting from the cloud, adding or removing a connector, changing forwarding, and license or tier changes. The acting operator is attributed to the signed-in user's identity rather than an anonymous "system" entry, so the trail answers "who changed what, and when." Writes are best-effort, so recording an event never blocks the action it is recording.
The audit log is readable in the console's Audit Log page, most-recent-first and filterable, with CSV and PDF export for compliance review. This on-prem trail is the counterpart to the immutable audit trail kept in the cloud; together they cover both sides of the boundary.
The collector console is also hardened at the web edge. Every response carries a fixed set of security headers:
| Header | Value |
|---|---|
Strict-Transport-Security | max-age=31536000; includeSubDomains |
X-Content-Type-Options | nosniff |
X-Frame-Options | SAMEORIGIN |
Referrer-Policy | strict-origin-when-cross-origin |
Permissions-Policy | geolocation=(), microphone=(), camera=() |
The same reverse proxy fronts every console API on the appliance, so these headers apply to the whole surface, not just static assets.
6. Token & secret rotation
| Secret | Rotation policy | Effect |
|---|---|---|
| Registration token | Single-use; expires automatically after 72 hours | Regenerate per collector enrolment |
| Collector identity token | Re-issued through re-registration before expiry | Revoke by deleting the collector in fleet view, which blacklists it |
| Ingest token | On demand or on suspected leak | Rotate in the tenant's integration config; the old token stops resolving immediately |
| Platform signing keys and database credentials | Scheduled, and on personnel change | Stored in a secret manager and injected at runtime, never committed |
Revoking a collector does not stop local collection: the appliance keeps working and simply shows as unregistered, in line with the collector autonomy principle.
7. Compliance mapping
The controls above map to common audit requirements. This is the engineering view, not a certification claim, so confirm current attestation status with your account contact.
| Requirement | How the platform satisfies it |
|---|---|
| SOC 2, Security | Single outbound boundary, signed collector identity, no inbound ports on-prem, gateway-only ingress |
| SOC 2, Confidentiality | Four-layer tenant isolation (section 2); per-tenant partitioning and rate quotas |
| SOC 2, Availability | Collector autonomy and store-and-forward buffering; HA collector pairing with fast failover |
| SOC 2, Audit | Immutable cloud audit trail, plus the append-only collector audit log (section 5) with operator attribution |
| GDPR, data minimisation | Raw credentials and the full firehose never leave the premises; only curated telemetry is forwarded |
| GDPR, data residency | The customer chooses what the collector forwards; on-prem stores hold the full dataset within the customer's jurisdiction |
| GDPR, right to erasure | Retention windows delete aged data automatically per tier; tenant deletion drops the tenant's partitions |
Hardening checklist
- Real CA TLS on the public endpoint, never a self-signed certificate
- All default credentials rotated before the portal is exposed
- Platform signing keys set to long random values from the secret manager
- Payload encryption enabled for Enterprise tenants, with the key injected rather than baked into the image
- Host volume encryption enabled beneath the databases
- Ingest tokens scoped per tenant, with a documented rotation runbook
| Related | Link |
|---|---|
| The boundary and pipeline these controls protect | Platform Architecture |
| Collector firewall and proxy posture | Data Collector Deployment |
| Auth-failure and RBAC triage | Troubleshooting |