Security¶
Security is a foundational design principle of the Zaita platform, not an afterthought. Every layer of the architecture — from control plane isolation to data storage segregation — has been engineered to minimise attack surface, enforce least privilege, and maintain strong trust boundaries. This page provides an overview of the key security properties of the platform.
Architectural Isolation¶
The Zaita platform separates internet-facing services from security-sensitive operations through distinct control planes. The SaaS control plane handles user interaction and API access, while the back control plane performs all cryptographic operations within an isolated boundary. These two planes communicate through an asynchronous job system — there is no direct network path from external interfaces to the back control plane or its Secured Back Control Plane.
This separation ensures that even in the event of a compromise of the SaaS control plane, cryptographic key material stored within the BCP and its dedicated data store remains protected. For a detailed breakdown of the control and data plane architecture, see the Architecture page.
Data Encryption¶
The Zaita platform employs multiple layers of encryption across its control and data planes, combining both symmetric and asymmetric cryptographic schemes depending on the sensitivity and operational requirements of each data category.
Customer-managed key (CMK) encryption is not supported. The platform's layered encryption architecture spans multiple control planes and data stores, each using different key types and cryptographic schemes. This interdependency makes a single externally-managed encryption key incompatible with safe and reliable platform operation.
Encryption at Rest¶
All customer operational data at rest within the primary data store (Source One) is encrypted using public key cryptography. Each tenant has a unique encryption key pair managed by the Secured Back Control Plane, ensuring that data belonging to one tenant cannot be decrypted by another.
When fully automated key pair and certificate generation results in the delivery of a private key, the requestor is required to supply an encryption key. The private key is encrypted before it leaves the back control plane, ensuring that unencrypted private key material is never accessible to the SaaS control plane or transmitted over external interfaces.
Target System Credential Encryption¶
Credentials for target systems — such as passwords and API keys used by Bridges to authenticate and deploy certificates — are stored using tenant-unique public key encryption. The encrypted credential and the corresponding tenant private key are deliberately held in separate storage locations: the credential in Source One, and the private key exclusively within Source Two under Secured Back Control Plane control.
Once a target system credential has been stored in the platform, it is not retrievable or visible to the SaaS (front) control plane or any operator. The credential is accessible only to the back control plane during active deployment operations.
Credential Distribution to Bridges¶
When a Bridge requires a target system credential to perform a deployment operation, the back control plane executes the following sequence:
- Loads the encrypted credential from the data store
- Decrypts it using the tenant's private key via the Secured Back Control Plane
- Re-encrypts the credential using the Bridge's short-lived public key
- Publishes the re-encrypted credential for retrieval by the Bridge
Bridge-specific encryption key pairs are short-lived, with a maximum lifetime of 24 hours. This ensures that even if a re-encrypted credential were intercepted in transit, it would be bound to a single Bridge instance and become unusable within 24 hours. These asymmetric key pairs are ephemeral and are never reused across sessions.
Identity and Access Management¶
Single Sign-On (SSO)¶
The Zaita platform supports single sign-on integration, allowing organisations to authenticate users through their existing identity provider. SSO reduces credential sprawl, centralises access governance, and enables organisations to enforce their own authentication policies — including multi-factor authentication — across the platform.
Roles and Permissions¶
Access within the platform is governed by a role-based access control (RBAC) model. Roles define the scope of actions a user may perform, ensuring that users are granted only the minimum level of access required for their responsibilities. Administrators can create users, assign roles, and manage permissions through the web portal.
Machine Accounts and Federated Identity¶
Machine accounts provide non-human authentication for automated integrations, including Bridges, Couriers, and customer-built API consumers. Machine accounts are purpose-built for programmatic access and are distinct from user accounts.
The platform supports federated identity authentication for machine accounts, enabling pipeline tooling and CI/CD platforms to authenticate without storing long-lived credentials. This allows organisations to leverage their existing identity federation infrastructure (such as OpenID Connect or cloud-native workload identity) to issue short-lived, scoped tokens for machine account authentication. By eliminating static credentials, federated identity significantly reduces the risk of credential leakage and simplifies key rotation.
IP whitelisting can be enforced on individual machine accounts, further restricting where authenticated API calls may originate from.
Tenant Segregation¶
In the multi-tenant deployment model, tenant segregation is enforced through individual customer encryption keys stored in a shielded data store that is isolated from the primary database. Each tenant's data is encrypted with their own key, ensuring that data cannot be decrypted or accessed by other tenants or by platform operators without the corresponding key.
For organisations requiring complete workload isolation, single-tenant deployments are available with dedicated control planes, data planes, and infrastructure. No resources are shared with other tenants.
Cryptographic Security¶
The platform's Secured Back Control Plane is designed to be compliant with FIPS 140-3 (Level 1), providing a verified baseline for cryptographic operations including key generation, signing, and storage. The Secured Back Control Plane operates exclusively within the back control plane and has no externally accessible interfaces.
For organisations with more stringent regulatory or compliance requirements, the platform supports integration with third-party physical HSMs or cloud-based HSM services, including those offered by Microsoft Azure and Amazon Web Services.
FIPS 140-3 Level 1 Compliance¶
The following table lists the required security functions and capabilities for FIPS 140-3 Level 1 compliance and their current implementation status within the Zaita Secured Back Control Plane.
| Requirement | Description | Status |
|---|---|---|
| Approved cryptographic algorithms | All cryptographic operations use only NIST-approved algorithms in approved modes of operation | TBD |
| Approved random bit generator (RBG) | Deterministic random bit generation using an approved DRBG mechanism (e.g., CTR_DRBG) seeded from an approved entropy source | TBD |
| Asymmetric key generation | RSA and elliptic curve (EC) key pair generation using approved methods and key sizes | Complete |
| Symmetric key generation | AES key generation using approved methods | Complete |
| Key establishment | Approved key agreement and key wrapping schemes (e.g., ECDH, RSA key encapsulation) | Complete |
| Digital signature generation | ECDSA or RSA-based signature generation | Complete |
| Digital signature verification | ECDSA or RSA-based signature verification | Complete |
| Hash functions | SHA-2 family (SHA-256, SHA-384, SHA-512) in approved operations | Complete |
| Symmetric encryption and decryption | AES in an approved mode of operation (e.g., AES-GCM, AES-CBC) | Complete |
| Message authentication codes (MAC) | HMAC or AES-CMAC for data integrity and authenticity | TBD |
| Power-up self-tests (known answer tests) | Automated known-answer tests for all cryptographic algorithm implementations executed at module initialisation | TBD |
| Conditional self-tests | Runtime tests including continuous RBG health checks and key pair consistency verification | TBD |
| Software integrity test | Cryptographic verification of module binary integrity at startup | TBD |
| Key zeroization | Secure erasure of all sensitive security parameters and key material from volatile memory on demand or module shutdown | Complete |
| Error state handling | Module transitions to and remains in an error state, inhibiting all cryptographic operations, upon self-test failure | TBD |
| Roles and authentication | Defined cryptographic officer and user roles with associated authentication for module management operations | Complete |
Audit Logging and SIEM Integration¶
The Zaita platform maintains comprehensive audit logs that capture all significant actions across the platform, including user authentication events, certificate lifecycle operations, machine account activity, and administrative changes.
Audit log data can be exported and integrated with external Security Information and Event Management (SIEM) platforms. SIEM integration enables organisations to correlate Zaita platform events with their broader security monitoring ecosystem, support incident detection and response workflows, and satisfy compliance and regulatory audit requirements.
Network Security¶
The platform enforces encrypted communications across all external and internal interfaces. All customer-facing endpoints are served over TLS. Internal communication between platform components follows defence-in-depth principles, with network-level access controls restricting connectivity between control planes and data stores to only the pathways required for operation.
Summary¶
| Capability | Description |
|---|---|
| Architectural isolation | Separate control planes for user-facing and cryptographic operations |
| Multi-layer data encryption | Layered symmetric and asymmetric encryption across control and data planes |
| Target system credential protection | Credentials encrypted with tenant-unique keys; private keys held in separate storage from credentials |
| Ephemeral Bridge credential distribution | Short-lived (<24 hours) asymmetric key pairs used for secure credential delivery to Bridges; front control plane never has access |
| Single sign-on (SSO) | Integration with external identity providers for user authentication |
| Federated identity for machine accounts | No-credential authentication via identity federation for automated integrations |
| Role-based access control | Least-privilege permissions model for all user and machine accounts |
| FIPS 140-3 (Level 1) Secured Back Control Plane | Compliant cryptographic module with support for third-party physical and cloud HSMs |
| SIEM integration | Audit log export for external security monitoring and compliance |
| Tenant segregation | Encryption-based isolation in multi-tenant; dedicated infrastructure in single-tenant |
| Network security | TLS on all external interfaces; defence-in-depth internal controls |