ANSSI SecNumCloud -- French Cloud Security Qualification¶
Framework Overview¶
Full name: Referentiel SecNumCloud v3.2 Issued by: ANSSI (Agence nationale de la securite des systemes d'information -- National Agency for Information Systems Security, France) Current version: v3.2 (2022) Type: Cloud security qualification (provider certification)
SecNumCloud is ANSSI's qualification framework for cloud service providers. It imposes over 360 requirements across 14 security themes, with a focus on ensuring that cloud data is protected from non-EU extraterritorial laws (particularly US CLOUD Act and FISA 702). SecNumCloud v3.2 introduced strict sovereignty requirements including EU ownership caps and data localization mandates.
Who Must Comply¶
- Cloud providers serving the French government, defense, and critical infrastructure
- Cloud providers processing sensitive data for French public and private organizations
- Increasingly referenced in French and EU procurement as the gold standard for sovereign cloud
Key Principles¶
- Immunity from non-EU laws: The provider must not be subject to extraterritorial non-EU legislation that could compel data disclosure
- EU data residency: All customer data and technical data must be stored and processed within the EU
- EU ownership and control: Non-EU shareholders capped at 25% individually, 39% collectively
- End-to-end encryption: Systematic encryption with keys under EU control
Relevant SecNumCloud Requirements and CloudTaser Mapping¶
Data Localization¶
| SecNumCloud Requirement | Description | CloudTaser Mapping | Component |
|---|---|---|---|
| Data residency in EU | All customer data must be stored on servers located in the EU | Vault (the key store) is hosted exclusively in the EU. Secrets never persist outside process memory -- they do not reach etcd, disk, or any US-controlled storage layer | Wrapper |
| Technical data in EU | System logs, metadata, and technical data must remain in the EU | eBPF security events and audit logs are generated locally on the Kubernetes cluster. CloudTaser does not transmit telemetry to non-EU destinations | eBPF, CLI |
| Support operations in EU | All system administration and support must be conducted from within the EU by EU-based personnel | CloudTaser is self-hosted on the customer's Kubernetes cluster. No remote access or external support channel exists by default. The SaaS control plane is EU-hosted | Operator |
Encryption and Key Management¶
| SecNumCloud Requirement | Description | CloudTaser Mapping | Component |
|---|---|---|---|
| Encryption of data in transit | All data in transit must be encrypted using strong cryptographic protocols | All vault communication uses TLS 1.2+ (mTLS when configured). Secrets are never transmitted in plaintext | Wrapper |
| Encryption of data at rest | Data at rest must be encrypted with keys under the provider's or customer's control | S3 proxy provides client-side AES-256-GCM encryption. Encryption keys remain in the EU-hosted vault and never reach the cloud provider | S3 Proxy |
| Data in use protection | Data being processed must be protected from unauthorized access | memfd_secret (kernel 5.14+) removes secret pages from the kernel direct map. Even root, kernel modules, and the hypervisor cannot read protected memory. eBPF blocks ptrace, /proc/pid/mem, and other memory access vectors |
Wrapper, eBPF |
| EU key control | Encryption keys must remain under the control of an EU entity | The EU-hosted vault (OpenBao/Vault) is operated by the EU data controller. The cloud provider has no access to vault keys. This is a technical guarantee, not a contractual one | Wrapper, S3 Proxy |
| Key lifecycle management | Keys must follow a documented lifecycle: generation, storage, rotation, destruction | cloudtaser rotate supports key rotation. Vault manages the key lifecycle within EU jurisdiction. Secret pages in memory are destroyed when processes exit |
Wrapper |
Access Control¶
| SecNumCloud Requirement | Description | CloudTaser Mapping | Component |
|---|---|---|---|
| Strict identity management | Only authorized personnel and systems may access data | Vault Kubernetes auth binds secret access to pod identity (ServiceAccount token + namespace). Only pods with correct binding access secrets | Operator, Wrapper |
| Multi-factor authentication | Access to sensitive systems must use MFA | Vault supports MFA for human operators. Pod authentication uses Kubernetes ServiceAccount tokens (machine identity), which are audience-bound and short-lived | Wrapper |
| Privileged access control | Privileged access must be strictly controlled and monitored | eBPF blocks all privileged memory access to protected processes: ptrace, /proc/pid/mem, process_vm_readv, kernel module loading. Even root cannot read memfd_secret pages |
eBPF |
| Access logging and audit trail | All access to data must be logged with tamper-evident audit trails | eBPF generates security events for all access attempts (blocked and allowed). Vault audit log records all secret fetch operations. cloudtaser audit produces compliance reports |
eBPF, CLI |
| Separation of duties | Administrative roles must be separated | The operator controls injection policy. Vault controls access policy. eBPF enforces runtime policy. No single component has full access | Operator, Wrapper, eBPF |
Immunity from Non-EU Laws¶
| SecNumCloud Requirement | Description | CloudTaser Mapping | Component |
|---|---|---|---|
| Protection from extraterritorial laws | The provider must demonstrate that non-EU laws (e.g., US CLOUD Act, FISA 702) cannot compel data disclosure | CloudTaser's threat model assumes the cloud provider has root access and is compelled by US law. Technical enforcement ensures secrets remain inaccessible regardless of legal compulsion | All |
| Technical measures against compelled disclosure | Technical controls must prevent data access even under legal pressure | memfd_secret removes secret pages from the kernel direct map. eBPF blocks all memory access syscalls. Secrets never touch persistent storage. The cloud provider is physically unable to extract secrets |
Wrapper, eBPF |
| Transparency of government access requests | The provider must disclose information about government access requests | Not directly addressed by CloudTaser. However, CloudTaser makes government access requests moot for secret data -- even if the cloud provider complies with a request, they cannot provide what they do not have | -- |
Incident Detection and Response¶
| SecNumCloud Requirement | Description | CloudTaser Mapping | Component |
|---|---|---|---|
| Security event detection | The provider must detect and respond to security events | eBPF agent detects 20+ attack vectors in real time: SECRET_LEAK, PROCMEM_READ, ENVIRON_READ, PTRACE_DENIED, MODULE_LOAD, BPF_LOAD |
eBPF |
| Incident response capability | The provider must have documented incident response procedures | On detection of a policy violation, the eBPF agent can terminate the offending process (reactive kill) or block the operation (proactive deny). Events are generated for SIEM integration | eBPF |
Component Coverage Matrix¶
| CloudTaser Component | SecNumCloud Themes Addressed |
|---|---|
| Operator (webhook injection) | Access control, identity management, separation of duties |
| Wrapper (secret delivery) | Encryption in transit, data in use, EU key control, data localization |
| eBPF (runtime enforcement) | Privileged access control, incident detection, immunity from non-EU laws, access logging |
| S3 Proxy (client-side encryption) | Encryption at rest, EU key control |
| DB Proxy (transparent encryption) | Encryption at rest, EU key control |
| CLI (audit, validate, discover) | Audit trail, compliance reporting, vulnerability identification |
Gaps and Limitations¶
CloudTaser is a customer-deployed data protection product, not a SecNumCloud-qualified cloud provider. The following areas are outside CloudTaser's scope:
| SecNumCloud Area | Gap | Mitigation |
|---|---|---|
| Provider ownership structure | SecNumCloud requires EU ownership caps (25% individual, 39% collective non-EU). CloudTaser cannot change a provider's ownership | CloudTaser makes the ownership question less critical for secret data -- even a non-EU-owned provider cannot access secrets. For full SecNumCloud compliance, use a qualified provider for the infrastructure and CloudTaser for defense-in-depth |
| Physical infrastructure location | SecNumCloud requires EU-located infrastructure. CloudTaser does not control where Kubernetes nodes run | The customer must deploy Kubernetes in EU regions. CloudTaser's vault must be EU-hosted. CloudTaser protects secrets even if the compute layer is in a non-EU jurisdiction |
| Personnel security | SecNumCloud requires EU-based personnel with security clearance for certain roles | Organizational measure, outside product scope. CloudTaser eliminates the need for cloud provider personnel to access secrets |
| Full provider certification | SecNumCloud qualifies cloud providers, not individual products | CloudTaser helps customers achieve SecNumCloud-equivalent protection on non-qualified providers through technical controls rather than provider certification |
| Contractual and legal framework | SecNumCloud includes legal and contractual requirements | CloudTaser provides technical measures. Contractual and legal measures are the customer's responsibility |
SecNumCloud is primarily a provider certification
SecNumCloud qualifies cloud providers, not their customers. CloudTaser helps customers of non-SecNumCloud-qualified providers (AWS, GCP, Azure) achieve equivalent technical protection guarantees. For organizations that require SecNumCloud-qualified infrastructure, CloudTaser provides an additional defense-in-depth layer on top of the qualified provider.
Audit Evidence¶
CloudTaser produces evidence relevant to SecNumCloud assessments:
# Generate compliance audit report
cloudtaser audit --vault-address https://vault.eu.example.com
# JSON output for evidence packages
cloudtaser audit --vault-address https://vault.eu.example.com -o json
The audit report provides:
- EU vault connectivity verification (data localization)
- TLS/mTLS configuration details (encryption in transit)
- Protection scores per workload (data in use protection)
- eBPF enforcement coverage per node (privileged access control)
- Orphaned Kubernetes Secrets inventory (data residency risk)