Security

Qpher is built as a microservices platform with clear security boundaries. The API Gateway handles authentication and rate limiting before routing requests to internal services. Private key operations are confined to the KMS-Orchestrator service, which is the only component with access to key material. All inter-service communication is authenticated with service tokens, and every request carries tenant context for isolation enforcement.

Reference: ADR-0001

Private keys are generated and stored exclusively within the KMS-Orchestrator secure enclave. No API endpoint, administrative interface, or internal service can export private key material. The database stores a key handle (a reference to the encrypted key file), never the key bytes themselves. All cryptographic operations requiring the private key — decryption and signing — are performed within the KMS-Orchestrator and the result is returned to the calling service.

Reference: ADR-0010

All private key files are encrypted using AES-256-GCM with a Key Encryption Key (KEK) that is itself managed through a multi-provider strategy. The KEK is a 256-bit key stored in environment secrets (transitioning to AWS KMS / GCP Cloud KMS for production). Each key file uses a unique initialization vector (IV) to ensure ciphertext uniqueness even for identical key material.

Reference: ADR-0010

Qpher uses a shared database with strict application-level tenant isolation enforced through four layers: (1) TenantScopedRepository base class that injects tenant_id into every query, (2) database-level CHECK constraints and composite unique indexes, (3) ServiceContext propagation ensuring tenant_id flows through all internal calls, and (4) API Gateway injection of tenant_id from the authenticated API key — tenant_id is never derived from user input.

Reference: ADR-0003

Every API request is evaluated by a dedicated Policy Engine service before reaching the target service. The engine applies a first-deny-wins rule chain that checks plan-based restrictions, quota limits, and method-level access controls. The Policy Engine fails closed by default: if the engine is unavailable, all requests are denied. An emergency fail-open mode exists with strict safeguards — it auto-reverts to closed after a configurable timeout (default 5 minutes) and generates critical audit events.

Reference: ADR-0007

Qpher is on a roadmap toward SOC 2 Type II certification. Phase 1 (v1.0): internal security controls documented and trust center published. Phase 2 (v1.1, 3-6 months post-launch): engage an independent auditor for SOC 2 Type I assessment. Phase 3 (v1.2, 6-12 months post-launch): complete the SOC 2 Type II observation period. All security practices described in this trust center are designed to satisfy SOC 2 Trust Services Criteria.

Reference: ADR-0022

All external traffic to Qpher APIs is encrypted via TLS 1.2+ (TLS 1.3 preferred). Internal service-to-service communication within the cluster uses mutual TLS where supported. The KMS-Orchestrator, which handles the most sensitive operations, requires TLS for all inbound connections. API keys are transmitted in request headers over HTTPS and are never included in URL parameters or query strings.