Security Architecture

This document details the security controls, encryption strategies, and compliance frameworks implemented in the platform.

Security Overview

The platform implements defense-in-depth with multiple security layers:

Layer Details:

Layer	Controls
Network Security	Network isolation per tenant, Least-privilege firewall rules, WAF and DDoS protections, Unidirectional routing between planes
Authentication & Authorization	JWT authentication (Admin Panel), Signed execution plans (CP to DP), OAuth for workspace integration, Least-privilege access roles
Data Protection	Encryption at rest (AES-256), Encryption in transit (TLS 1.3), Tamper-resistant signed plans, Metering-sidecar signatures
Runtime Protection	Restricted tags with SCP enforcement, Tamper detection, Monitoring and alerting, Threat detection

Authentication & Authorization

Admin Panel Authentication

Uses an Identity Provider for secure user authentication:

Token Specifications:

• Algorithm: RS256 (RSA with SHA-256)
• Expiration: 1 hour (configurable)
• Refresh: 30 days (stored in HttpOnly cookie)
• Claims: sub, email, email_verified, user_groups

Execution Plan Signing (CP to DP)

All execution plans sent from Control Plane to Data Plane are signed with ES256 (ECDSA with SHA-256):

JWT Claims:

• Issuer: Control Plane API endpoint
• Subject: Tenant ID
• Audience: Data Plane for specific tenant
• Expiration: 5 minutes (short-lived)
• Plan Hash: SHA-256 digest of execution plan for tamper detection

Validation Steps:

1. Fetch public key from JWKS endpoint
2. Verify ES256 signature
3. Check token expiration
4. Verify plan hash matches

Encryption

Encryption at Rest

Resource	Encryption Method	Key Management
Database Tables	AES-256	Platform-managed keys
Object Storage	AES-256	Storage-managed keys
Block Storage	AES-256	Platform-managed keys
Secrets Manager	AES-256	Platform-managed keys
Log Storage	AES-256	Platform-managed keys

Encryption in Transit

All API communication uses TLS 1.3 with strong cipher suites:

Cipher Suites (in preference order):

1. TLS_AES_128_GCM_SHA256
2. TLS_AES_256_GCM_SHA384
3. TLS_CHACHA20_POLY1305_SHA256

Cryptographic Signatures

Metering Sidecar Signatures (Ed25519)

The metering sidecar signs all heartbeats with Ed25519 for tamper-proof reporting:

Signature Components:

• Algorithm: Ed25519 (fast elliptic curve signatures)
• Counter: Monotonic counter prevents replay attacks
• Timestamp: Unix timestamp for temporal validation
• Signature: 64-byte Ed25519 signature
• Encoding: Base64 for transmission

Security Properties:

• Tamper-proof: Any modification invalidates signature
• Replay protection: Monotonic counter ensures uniqueness
• Non-repudiation: Public key cryptography proves origin

Network Security

Network Isolation

Each tenant receives an isolated private network:

Firewall Rules

Least-privilege access with explicit allow rules:

Key Restrictions:

• Inbound: Only Control Plane can reach Data Plane (port 5678)
• Outbound: HTTPS only (port 443) to Control Plane and internet
• Denied: All inbound from internet, SSH access disabled
• Network Isolation: Each tenant has dedicated network (10.(100+N).0.0/16)

## Runtime Protection

### Tag-Based Policy Enforcement

Critical infrastructure resources are protected by **organizational policies**:

**Protected Resources:**
- Workflow runtime Auto Scaling Groups
- Metering sidecar binaries
- Network and Firewall configurations
- NAT Gateways

### Tamper Detection (Metering Sidecar)

The metering sidecar includes **anti-debugging** and **integrity checks**:

1. Check if debugger is attached
2. Verify binary hash (prevent replacement)
3. Check UID (prevent privilege escalation)
4. Check parent process (prevent hijacking)

## Threat Detection & Monitoring

### Threat Detection Service

Continuous threat detection across all accounts with alerts on high-severity findings.

### Security Monitoring

**Security-critical alarms:**

| Alarm | Threshold | Description |
|-------|-----------|-------------|
| Failed Authentication | > 50 in 5 min | Potential brute force attack |
| Tamper Detected | > 0 | Metering sidecar compromise |
| API Traffic Spike | > 100k req/5min | Potential DDoS attack |

## Compliance Frameworks

### GDPR Compliance

| Requirement | Implementation |
|-------------|----------------|
| **Right to Access** | Data export API endpoint |
| **Right to Erasure** | CASCADE deletion endpoint |
| **Data Minimization** | Outcomes exclude PII |
| **Encryption** | AES-256 at rest, TLS 1.3 in transit |
| **Data Residency** | Deploy in EU regions |
| **Breach Notification** | Automated alerts |

### HIPAA Compliance (Eligible)

Platform services used are **HIPAA-eligible**:
- NoSQL database (with encryption)
- Object storage (with encryption)
- Serverless compute (stateless, encrypted environment variables)
- API Gateway (TLS 1.3)
- Log storage (encrypted logs)
- Network isolation

### SOC 2 Type II

| Control | Implementation |
|---------|----------------|
| **CC6.1 - Logical Access** | MFA, least-privilege access control |
| **CC6.6 - Encryption** | AES-256 at rest, TLS 1.3 in transit |
| **CC7.2 - Monitoring** | Metrics, threat detection, audit logs |
| **CC7.3 - Incident Response** | Automated alerts, runbooks, 24/7 on-call |
| **CC8.1 - Change Management** | CI/CD pipelines, IaC drift detection |

## Incident Response

### Security Incident Classification

| Severity | Examples | Response Time |
|----------|----------|---------------|
| **Critical** | Data breach, unauthorized access | < 15 min |
| **High** | Threat detection high-severity, tamper detected | < 1 hour |
| **Medium** | Failed auth spike, unusual API activity | < 4 hours |
| **Low** | Expired certificate warning | < 24 hours |

### Incident Response Workflow

```mermaid
flowchart LR
  D[Detection] --> T[Triage]
  T --> C[Containment]
  C --> E[Eradication]
  E --> R[Recovery]
  R --> P[Post-Incident Review]

Security Best Practices

For Administrators

1. Enable MFA on all user accounts
2. Rotate credentials every 90 days
3. Review audit logs weekly
4. Update dependencies monthly
5. Run security scans weekly

For Developers

1. Never commit secrets - use secure secrets management
2. Use least-privilege access policies
3. Validate all inputs - prevent injection attacks
4. Log security events
5. Test disaster recovery quarterly

For Tenants

1. Use strong credentials for integrations
2. Limit API access - disable unused workflows
3. Monitor quota usage - detect anomalies
4. Review audit logs
5. Report security concerns promptly

Security Audits

Internal Audits

• Frequency: Quarterly
• Scope: Access policies, firewall rules, audit logs
• Tools: Automated compliance scanning

External Penetration Testing

• Frequency: Annually
• Scope: API Gateway, Admin Panel, Data Plane isolation
• Provider: Third-party security firm