Skip to content

Security & Trust

Security is a foundational design constraint of the Naburis platform, not an afterthought. This page describes the controls, architecture, and processes that protect customer data across every product.

Security contact: security@naburis.cloud


Naburis provides a centralized OIDC identity provider, self-hosted within the platform boundary.

CapabilityDetail
ProtocolOpenID Connect 1.0 / OAuth 2.0
Browser appsAuthorization Code + PKCE
Machine-to-machineClient Credentials grant or Personal Access Tokens
Token formatJWT (RS256), verified against JWKS endpoint
Token verificationEvery service independently validates JWTs — no shared session state
SSO federationAny OIDC-compatible identity provider can federate via the platform’s IdP
Session managementShort-lived access tokens with refresh token rotation

Custom JWT claims carry platform context (tenant, plan, and product entitlements), enabling products to enforce plan-specific behavior without additional lookups. See Authentication for integration details.


Authorization is enforced with a deny-by-default policy — if the policy engine is unreachable, the request is denied (HTTP 503), not silently allowed.

Access tiers:

TierScopeHow
Platform AdminIdentity, billing, customer managementScoped admin roles, API keys
Product UserPer-product data and APIsOIDC JWT with product-specific claims, workspace-scoped headers

Each API request is scoped by three mandatory headers — X-Tenant-ID, X-Workspace-ID, and X-Context-ID — verified against JWT claims before reaching any product service.


Every API request is logged with both the service identity (which service made the call) and the delegated user identity (on whose behalf).

Event typeRetention
API requests30 days
Authentication eventsPer identity provider policy
Configuration changes30 days

Naburis enforces logical tenant isolation at every layer of the stack:

LayerIsolation mechanism
API gatewayMandatory scope headers validated against JWT
DatabasePer-product database roles — no cross-database access permitted
CacheNamespaced key isolation with access control per product
Knowledge graphGraph-level isolation; each tenant’s data lives in distinct graphs
Object storagePer-product bucket isolation

Tenant identifiers propagate from the JWT through every service boundary. A request cannot access data outside its tenant/workspace scope.


TopicDetail
Data residencyEU by default; configurable per deployment
Encryption in transitTLS 1.2+ on all endpoints, automated certificate management
Encryption at restDatabase volume-level encryption; secrets encrypted before storage
Data export (GDPR Art. 20)Full data portability via Export service — CSV, JSON, or Parquet format
Right to erasure (GDPR Art. 17)Hard-delete capability removes data from all stores, including downstream projections
Soft-delete defaultRecords are tombstoned, recoverable within retention window; only GDPR erasure requests trigger permanent deletion
CORSProduction origins must be explicitly listed — wildcard origins are not permitted when credentials are in use

No plaintext secrets are stored in version control.

ControlDetail
Encryption at restSecrets encrypted before commit, decrypted at deploy time
RotationRegular rotation schedules for database credentials, master keys, and SSH keys
Automated rotationTooling generates, updates, restarts, and verifies in a single run
Service-to-service authMachine users with rotatable tokens — no static secrets in application configuration

AspectDetail
ScheduleDaily automated backups
ScopeDatabases, application volumes, platform configuration
Retention30 days on-host
Off-host replicationEncrypted sync to cloud object storage
MonitoringAlert fires if no successful backup within the expected window
Restore proceduresDocumented and tested: full-server, database-only, and volume-only restore

ControlDetail
Host OSLTS Linux with unattended security updates
ContainerizationAll application code runs in containers with resource limits
SSH accessKey-only authentication, password login disabled
Infrastructure-as-codeEvery deployment is repeatable and auditable
Policy gatesAll configurations validated before deploy
Container policyNo privileged containers, resource limits required, restart policies mandatory
Vulnerability scanningContainer images scanned for critical and high-severity CVEs; builds blocked on findings
Reverse proxyAutomatic HTTPS, security headers (HSTS, CSP, X-Content-Type-Options), multi-layer rate limiting

Naburis follows a structured incident response process with defined severity levels and escalation procedures. Response times and procedures are documented internally and reviewed regularly. For urgent security matters, contact security@naburis.cloud.


Naburis is not yet SOC 2 or ISO 27001 certified. We believe transparency about our current controls is more valuable than vague compliance claims:

Controls in place today:

  • ✓ Encryption at rest and in transit (TLS 1.2+)
  • ✓ OIDC-based authentication with MFA support
  • ✓ Role-based access control with deny-by-default policy enforcement
  • ✓ Audit logging with delegated identity attribution
  • ✓ Automated daily backups with off-host replication and monitoring
  • ✓ Vulnerability scanning on every container image
  • ✓ Secret rotation schedules with automated tooling
  • ✓ Incident response process with severity classification
  • ✓ GDPR data export and right-to-erasure support
  • ✓ Infrastructure-as-code with policy-gated deployments

Formal compliance certification is on our roadmap. If you have specific compliance requirements, contact us at security@naburis.cloud.