Architecture¶
The Zaita platform architecture is founded on the principles of least privilege, separation of duties, and zero trust. It is organised into distinct control planes and data planes — control planes manage user interaction and task execution, while data planes provide isolated, purpose-built storage. This separation enables independent scaling, security hardening, and operational management of each component.
Control Planes¶
The platform consists of two control planes, each serving a distinct role in the overall request lifecycle:
- SaaS Control Plane (FCP) — the externally facing interface for users and integrations.
- Back Control Plane (BCP) — the internal execution engine for cryptographic and certificate lifecycle operations.
SaaS Control Plane¶
The SaaS control plane is the internet-facing component of the Zaita platform. It hosts the web portal, REST APIs, and all customer-facing interfaces. User authentication, authorisation, and session management are all handled within this plane. It is the primary entry point for certificate management, account administration, and reporting.
Back Control Plane¶
The back control plane operates alongside the SaaS control plane but exposes no externally accessible interfaces. It is the core execution engine of the architecture, responsible for security-sensitive and computationally intensive operations — including cryptographic key pair generation, certificate signing request (CSR) creation, and certificate issuance.
All cryptographic operations are confined within the back control plane. The SaaS control plane interacts with it indirectly, submitting work requests through an asynchronous job system. The back control plane fulfils those requests and returns only non-sensitive results — such as signed certificates or public keys — to the SaaS control plane. Private key material is generated, used, and stored entirely within the back control plane's boundary.
This design enforces a strong trust boundary between user-facing services and cryptographic operations. Even in the event of a full compromise of the SaaS control plane, the back control plane's isolation ensures that cryptographic key material remains protected.
Note: When fully automated key pair and certificate generation is used, the platform must deliver the private key to the target system or make it available for download. In such cases, the requestor must supply an encryption key, which is used to encrypt the private key before delivery. The SaaS control plane never has access to the unencrypted private key. When a Bridge is used, the Bridge provides uses rotating asymmetric public keys.
Data Planes¶
The platform uses two logically separated data stores, each purpose-built for its respective control plane. This separation enforces strict access boundaries and limits the blast radius of any single point of compromise.
Both data stores use independent symmetric encryption at rest and tenant-independent asymmetric encryption keys. Neither store shares encryption keys or key material with the other.
FCP Data Store¶
The FCP data store is the primary relational data store, directly connected to the SaaS control plane. It holds customer operational data including account configuration, certificate metadata, and audit records.
BCP Data Store¶
The BCP data store is used exclusively by the back control plane. It holds cryptographic key material, job orchestration state, and task lifecycle records. It has no direct network connectivity to the SaaS control plane — all access is mediated through the back control plane's internal layer.
Secured Back Control Plane — Roadmap¶
The Secured Back Control Plane is a planned capability on the Zaita platform roadmap. It will be implemented as a dedicated Rust binary module within the back control plane. Running as a native binary enables fine-grained control over memory operations — including explicit zeroing of sensitive key material from memory — beyond what is achievable within a general-purpose application runtime.
Once delivered, the Secured Back Control Plane will serve as the authoritative boundary for all cryptographic key generation, storage, and signing operations within the back control plane. It is designed to be compliant with FIPS 140-3 (Level 1). For organisations with more stringent compliance or regulatory requirements, the platform will also support integration with third-party physical HSMs or cloud-based HSM services from Microsoft Azure and Amazon Web Services.