Security Concept & TOMs (Technical and Organizational Measures)

This document details the security architecture of the vHaaS platform and the concrete Technical and Organizational Measures (TOMs) implemented to safeguard customer data, test systems, and intellectual property.

1. Security Philosophy

Our security design rests on two fundamental pillars: Security by Design and Zero Trust.

                       [Public Internet]
                               │
                    WAF + DDoS Protection
                               │
                         [Zero-Trust]
                               │
               ┌───────────────┴───────────────┐
               ▼                               ▼
       Platform UI / API               Outbound Tunnel
        (Auth via OIDC)              (No Inbound Ports)
               │                               │
       Multi-Tenant DB                         ▼
       (AES-256 Encrypted)             Execution Environment
                                          (Isolated LAN)

Instead of trusting requests based on their origin, we verify every single transaction. We employ a multi-layered security strategy ("Defense in Depth") to ensure that if a single security control fails, redundant barriers remain active.

2. Platform & Architectural Security

2.1 Attack Surface Reduction (Outbound-Only Tunnels)

Traditionally, remote hardware control required open inbound firewall ports or complex client-to-site VPNs. vHaaS completely eliminates this risk: * Outbound Connections Only: The vHaaS Agent on the Execution Environment (EE) initiates outbound connections to the central cloud platform via a secure outbound tunnel. Currently, Cloudflare Tunnel is used for this purpose; we reserve the right to activate alternative tunnel solutions in the future. * No Inbound Ports: No inbound firewall ports are opened on the client's local network. Your internal development environments and physical test rigs remain completely invisible to the public internet, preventing automated port scans and unauthorized access attempts.

2.2 Datacenter Infrastructure & Sub-Processors

The vHaaS Cloud platform (Application Service (AS)) is deployed on Amazon Web Services (AWS) using modern Infrastructure as Code (IaC) workflows. * IaC-Driven Deployments: All cloud configurations are defined programmatically, minimizing human error and configuration drift. * Datacenter Standard: AWS datacenters maintain top-tier physical security standards, redundant power routing, and robust disaster recovery capabilities.

2.3 Web Application Firewall & DDoS Protection

vHaaS uses a layered WAF approach: * Platform WAF: The vHaaS WebService (Platform UI and API) is protected by a dedicated Web Application Firewall that mitigates injection attacks, cross-site scripting (XSS), and malicious API abuse. * Tunnel-Level Protection: The outbound tunnel layer additionally provides DDoS protection against high-volume Layer-3, 4, and 7 denial-of-service attacks. * Certifications of the Tunnel Provider (Cloudflare): Our current tunnel provider maintains major certifications: * ISO 27001: Standardized Information Security Management System (ISMS). * SOC 2 Type II: Continuous audit of security, availability, and confidentiality controls. * BSI C5:2020: High-level Cloud Computing Compliance Controls Catalogue verified by the German Federal Office for Information Security (BSI).

3.1 EU Data Localization

To address Schrems-II rulings and stringent EU data privacy laws, the following measures apply: * AWS Region: The vHaaS platform is hosted in EU-based AWS regions. All application data at rest is stored within the EU. * Tunnel-Level EU Routing: Cloudflare offers a Data Localization Suite that restricts tunnel traffic processing (including WAF inspection of headers and metadata) to datacenters within the EU. This option is available but is not enabled by default. It can be activated on request. * GDPR Alignment: Data Processing Agreements (DPAs) are in place with all relevant sub-processors.

3.2 Transit & At-Rest Encryption

Data In-Transit: All client-to-cloud and cloud-to-agent communication is strictly encrypted using TLS 1.3 and SSH (using secure, modern cyphers).
Data At-Rest: Databases, backups, and logs are encrypted at rest using industry-standard AES-256 algorithms.

4. Identity & Access Governance (IAM)

4.1 Single Sign-On (SSO) & MFA

Federated Identity: We support integration with enterprise identity providers (IdPs) like Microsoft Entra ID (Azure AD) and Okta via SAML 2.0 or OIDC.
Multi-Factor Authentication (MFA): MFA enforcement is planned for all platform accounts. During the current pilot phase, MFA is not yet active; it will be enabled as part of the general availability release.

4.2 Fine-Grained Authorization (ReBAC)

Access is controlled using a Relationship-Based Access Control (ReBAC) model. * Permissions are evaluated at the exact moment of request execution. * Strict logical tenant separation is enforced at the database level, ensuring users cannot view or interact with hardware catalog items belonging to other organizations.

4.3 Comprehensive Audit Logs

Every security-relevant activity (logins, session creations, user role modifications, hardware booking, command execution) is logged and stored in non-tamperable audit logs.

5. Technical and Organizational Measures (TOMs)

The following is the consolidated register of concrete technical and organizational measures implemented for vHaaS in accordance with Article 32 of the General Data Protection Regulation (GDPR). It is the shared deliverable between the vHaaS security and legal/compliance functions and is intended for procurement, data-protection, and legal review by prospective and pilot clients.


Service	vHaaS (Vector Hardware as a Service)
Version	1.0
Legal basis	Art. 32 GDPR

5.1 Physical Access Control (Zutrittskontrolle)

Measures to prevent unauthorized persons from gaining physical access to data-processing facilities.

AWS data centers apply physical access controls certified under SOC 2, ISO 27001, and CSA STAR Level 2; access is restricted to authorized AWS personnel.
Vector offices are TISAX-certified with badge-based access and visitor management.
Customer data is not stored on local workstations.
For on-premises hardware, physical security is provided by the customer's infrastructure; media sanitization is handled by Vector's device-management processes.

5.2 System Access Control (Zugangskontrolle)

Measures to prevent unauthorized use of data-processing systems.

Single Sign-On (SSO) via Vector ID — no local passwords.
Multi-factor authentication provided through the SSO identity provider; enforcement is being rolled out and completes at general availability.
JWT validation with explicit audience checks per RFC 7519.
API access tokens are stored as HMAC-SHA256 hashes with a server-side pepper and enforced expiration; raw token values are never stored.
Registration tokens are one-time use, SHA-256 hashed, with a one-hour time-to-live and are atomically invalidated on first use.
Authentication failures are logged with structured reason codes.

5.3 Data Access Control (Zugriffskontrolle)

Measures to ensure authorized users can only access data within their access rights.

Relationship-Based Access Control (ReBAC) implemented with OpenFGA across resource types with granular relations (read / update / delete / admin / connect).
Authorization checks are enforced on every API endpoint, with startup validation preventing misconfiguration.
Role hierarchy: instance admin / organization admin / group admin / user.
Authorization denials return 404 Not Found rather than 403 Forbidden to prevent resource enumeration.
Role changes are logged with old and new values.

5.4 Separation Control (Trennungskontrolle)

Measures to ensure data collected for different purposes is processed separately.

Multi-tenancy enforces organization-scoped data isolation at both the database-query and ReBAC levels.
Separate AWS accounts per environment (development / staging / production).
Kubernetes namespace isolation.
Visibility filtering ensures users only see resources to which they have an explicit relation.

5.5 Pseudonymization (Pseudonymisierung)

Measures for the pseudonymization of personal data.

Internal user identifiers (from the identity provider's sub claim) are used instead of names in logs and internal references.
Tokens are stored as HMAC-SHA256 hashes — raw values are never persisted.
Logging middleware redacts sensitive parameters (e.g. tokens, tickets, API keys).
WebSocket tickets are encrypted with an embedded user identifier.

5.6 Encryption (Verschlüsselung)

Measures to protect personal data through encryption.

In transit:

TLS 1.3 enforced at the web tier.
HSTS header enabled.
S3 bucket policies deny non-TLS access.

At rest:

RDS PostgreSQL storage encrypted with an AWS KMS key.
S3 buckets use SSE-KMS with a dedicated key and automatic rotation.
EBS volumes encrypted via the gp3 StorageClass.
Secrets Manager uses a dedicated KMS key with automatic rotation.
Provider tokens are encrypted before storage in Vault / Secrets Manager.

5.7 Transfer Control (Weitergabekontrolle)

Measures to ensure personal data cannot be read, copied, or altered without authorization during transmission.

All external communication runs over TLS.
S3 bucket policies deny non-HTTPS access.
No data-export functionality to unencrypted channels.
VM credentials are transmitted only via encrypted WebSocket tickets.

5.8 Input Control (Eingabekontrolle)

Measures to ensure it can be verified who entered, modified, or removed personal data.

Request middleware logs user ID, IP address, timestamp, HTTP method, URL path, and status code.
Authentication failures and role changes are logged with structured reason codes.
Logs are shipped to Loki with OpenTelemetry trace context.
Retention period: at least 30 days.
Logging cannot be disabled by application users.

5.9 Availability Control (Verfügbarkeitskontrolle)

Measures to ensure personal data is protected against accidental destruction or loss.

RDS Multi-AZ deployment with a read replica and 7-day automated backups.
AWS Backup: daily (35-day retention) plus weekly (90-day retention).
EBS daily snapshots with 14-day retention.
S3 versioning on all buckets with 90-day noncurrent-version expiration.
Multi-node Kubernetes cluster across availability zones.
Deletion protection enabled on the production database.

5.10 Resilience (Belastbarkeit)

Measures to ensure the resilience of systems and services.

Kubernetes cluster with on-demand and spot node groups across three availability zones.
RDS read replica for read scaling.
Horizontal pod autoscaling.
Service mesh for reliable service-to-service communication.

5.11 Recoverability (Wiederherstellbarkeit)

Measures for the rapid restoration of availability of personal data after an incident.

RDS point-in-time restore (up to 7 days back).
AWS Backup for longer retention (35 / 90 days).
Infrastructure as Code — full environments are recreatable.
GitOps-based deployment — workloads are auto-deployed from version control.
Documented DR plan with RTO/RPO targets (e.g. RDS failure RTO ~30 minutes; cluster loss RTO 2–4 hours).
DR tests scheduled quarterly, semi-annually, and annually.

5.12 Regular Review Procedures (Verfahren zur regelmäßigen Überprüfung)

Measures for regular testing, assessment, and evaluation of the effectiveness of the technical and organizational measures.

MVSP self-assessment performed annually.
Independent gray-box penetration test conducted April 2026, recurring annually.
Automated dependency updates (Renovate) and container-image vulnerability scanning (Trivy).
Software Composition Analysis (Black Duck) on every release.
DR test plan: quarterly restore test, semi-annual full-stack test, annual full DR simulation.

5.13 Sub-processor Management (Auftragsverarbeitung)

Overview of sub-processors and their compliance status.

Sub-processor	Purpose	Compliance certifications
AWS (Amazon Web Services)	Cloud infrastructure, compute, storage, database	SOC 2, ISO 27001, CSA STAR Level 2
Vector ID	Identity provider (SSO)	Vector internal
Cloudflare	CDN, DNS, tunnel management	SOC 2 Type II, ISO 27001

Sub-processors are assessed annually by reviewing their compliance certifications.

5.14 Data Protection Management (Datenschutzmanagement)

Organizational measures to ensure data protection.

GDPR compliance is implemented as defined in the AVV (Auftragsverarbeitungsvertrag) and DPA (Data Processing Agreement).
A dedicated customer security-contact channel is maintained for security notifications.
Security self-training completed (OWASP, secure development practices); secure-coding guidelines are documented for developers.
Strict input validation (Pydantic schemas), HTML-sanitization middleware, and standardized RFC 9457 error responses.
All database access uses the SQLModel ORM (no raw SQL).
A sensitive-data inventory is maintained and available to customers on request.