Encryption & Security Architecture

Version: 1.0  ·  Effective date: May 2026  ·  Owner: Cloudryption Security & Privacy

1. Architecture overview

Cloudryption consists of a browser UI, API service, background workers, cloud connectors, a normalisation and facts layer, a graph snapshot store, findings and control engines, an attack-path engine, recommendation and remediation logic, reporting, audit logging pipeline, and optional integrations such as AI narrative generation, support, email, and monitoring.

The primary data flow is:

1. Customer authorises a cloud connector with least-privilege read-only permissions
2. Connector reads cloud metadata (IAM, network, storage, compute, Kubernetes resources)
3. Normalisation and facts layer maps resources, identities, network topology, and data signals into a canonical model
4. A graph snapshot is created representing the customer's cloud environment at a point in time
5. Findings, control, and attack-path engines evaluate the snapshot and produce prioritised results
6. Recommendations and reports are generated linked to the source graph snapshot
7. Users review evidence and decisions through the UI or API

2. Encryption in transit

• All customer browser and API connections use HTTPS / TLS 1.2+
• Internal service-to-service, database, and cloud-provider API connections use TLS where supported by the provider
• Obsolete TLS protocols (TLS 1.0, 1.1) and weak cipher suites are disabled at the production edge
• HSTS (HTTP Strict Transport Security) is enforced for the public-facing platform

3. Encryption at rest

• Cloud provider and database-native encryption at rest for all production databases, object storage, and backups
• Key management via cloud KMS (e.g., AWS KMS) with access restricted to required service roles and authorised administrators
• KMS key access is logged and audited
• Plaintext secrets are not stored in source code, logs, exports, analytics, or customer-visible reports

4. Secrets and connector credential handling

Cloudryption recommends and supports cloud-native role assumption, workload identity, delegated read-only roles, and short-lived credentials over long-lived static keys.

Where credentials must be stored (e.g., for cross-account connector access):

• Credentials are stored encrypted in a secrets manager or encrypted credential store
• Access is restricted to the connector service role and authorised administrators
• Secret values are never logged, exported, or included in customer-visible content
• Connector setup, changes, and scan failures are logged with timestamps and actor identifiers

Credential rotation and revocation procedures are documented and tested. Customers can revoke connector access at any time through the platform or by removing the cloud role / policy from their cloud provider.

5. Tenant and run isolation

All application logic enforces tenant_id and user role before reading or modifying any tenant data. This check occurs at the HTTP handler, service, and database query layers.

Scan outputs are scoped by tenant_id, env_id, and run_id. Findings, attack paths, recommendations, reports, and evidence artefacts are linked to the specific graph snapshot used for calculation, preventing cross-run contamination.

Cross-tenant access is covered by automated negative tests that run in CI on every pull request. Any regression that allows cross-tenant data access would fail the test suite.

6. Evidence minimisation

Security evidence is designed to be sufficient to explain decisions without including unnecessary sensitive content:

• IAM / access evidence: policy excerpts, rule identifiers, permission names, resource IDs, timestamps, and provider references — not raw credential values
• Network evidence: port, protocol, source/destination metadata, security group rule IDs — not packet captures
• Storage evidence: bucket/object ACL metadata, public access settings, encryption status — not raw bucket contents
• DSPM / data classification: counts, confidence scores, reasons, hashes, redacted snippets — not raw data samples

Cloudryption does not intentionally require customers to provide production application payloads, secrets, private keys, passwords, raw database contents, or regulated personal records for normal operation.

7. Optional AI security architecture

AI-assisted narrative generation is disabled by default. When enabled by an authorised tenant administrator:

• Processing is limited to selected findings, attack-path summaries, and report inputs
• Raw secrets, production payloads, and regulated personal records are excluded by design
• AI events are logged and visible in the audit trail
• AI output does not replace deterministic engine evidence — source evidence links are always preserved
• The UI clearly indicates when content is AI-assisted
• Customers can disable AI processing at any time; the applicable AI provider is listed on the Subprocessors page

8. Data-flow controls summary