Tenant Isolation

1.1 Defense in depth is not a metaphor

In classical cybersecurity, defense in depth is a theoretical principle. In a shared infrastructure hosting MSP clients with conflicting interests, it becomes a vital necessity. A managed service provider may simultaneously host a law firm, a clinic, and a direct competitor of the former — on the same physical server.

The traditional multi-tenant approach relies on application-level separation: the application filters queries according to a tenant_id. This approach fails spectacularly when a bug, an injection flaw, or a privilege escalation bypasses that single layer.

1.2 The biological model: cell membrane and tight junctions

The human intestinal epithelium illustrates our paradigm. Each cell has its own phospholipid membrane — that is the first barrier. Between cells, tight junctions form a second barrier, impermeable even to small molecules. A third barrier — the glycocalyx — filters macromolecules. None of these barriers is sufficient on its own; their superposition creates a seal close to the absolute.

1.3 The nine layers

2.1 Row-Level Security (Layer 1)

PostgreSQL Row-Level Security is the deepest mechanism of isolation. Every row of every table carries a tenant_id. An RLS policy applied to each table guarantees that the PostgreSQL session connected for tenant A physically cannot read tenant B's rows.

The current_setting function reads a PostgreSQL session variable. This variable is set by the connection pool at tenant authentication time. No application query can modify it — it is read-only from the application side. This layer is inviolable without PostgreSQL superuser access.

2.2 Schema per tenant (Layer 2)

Beyond RLS, each tenant has a dedicated logical schema — not a PostgreSQL schema in the CREATE SCHEMA sense, but a restricted data projection. Materialized views, partial indexes, and sequences are filtered by tenant_id. A tenant cannot enumerate the other tenants, because the tenants table itself is protected by RLS.

This layer prevents inference attacks: even if a tenant managed to measure the execution time of a query (timing attack), the partial indexes guarantee that other tenants' data is never scanned.

2.3 Constraints and triggers (Layer 3)

The third PostgreSQL layer uses CHECK constraints and BEFORE INSERT/UPDATE triggers to prevent writing data that would violate isolation:

An additional trigger locks any attempt to modify the tenant_id column after insertion. This redundancy is deliberate: if the RLS policy is disabled by mistake (for example during maintenance), the constraints and triggers maintain isolation.

3.1 SPINA v2 — Per-tenant signing (Layer 4)

SPINA (Signature Protocol for Integrity and Non-repudiation of Assets) is 0DATA's signing protocol. In version 2, each tenant has:

• A local HMAC-SHA256 key, generated and stored in the tenant's space
• An eIDAS RFC 3161 certificate for qualified timestamping
• An isolated keystore, encrypted with a passphrase derived from the tenant's secret

Two tenants never share cryptographic material. If tenant A compromises its HMAC key, tenant B's signatures remain valid. The eIDAS timestamping is federated at the infrastructure level, but the timestamp token is stored in the tenant's schema.

Signature verification is executed in the tenant's PostgreSQL context. The spina_verify() function uses SECURITY DEFINER with an explicit SET app.current_tenant_id — it cannot leak outside the tenant.

3.2 NOVA — Instance per tenant (Layer 5)

NOVA is the network observation engine. Each MSP tenant has its own NOVA instance, run as a dedicated process:

• Exclusive bind on 127.0.0.1, distinct port for each tenant
• Local scan database (SQLite or isolated PostgreSQL schema)
• No memory sharing between instances
• Distinct configuration file (/opt/nova/tenants/<tenant_id>/config.yaml)

A tenant who controls its local network (and therefore the targets scanned by NOVA) cannot influence another tenant's NOVA instance. The processes are isolated at the operating-system level — kill -9 on tenant A's PID does not affect tenant B.

3.3 ALFA — Shared engine, isolated memory (Layer 6)

ALFA (Analytics Layer for Forensic Assessment) is the shared decision-making engine. Unlike NOVA, ALFA uses a shared engine for resource efficiency, but with strict memory isolation:

• Each analysis level (tenant, site, equipment) is compartmentalized
• Data is loaded into sealed memory segments
• Analysis results are written to the tenant's PostgreSQL schema
• No cross-tenant correlation is performed without explicit consent

ALFA applies the need-to-know principle at the algorithmic level: an analysis model run for tenant A receives only tenant A's data. Multi-tenant aggregate statistics (useful for benchmarking) use anonymized data with differential privacy (ε = 1.0).

4.1 Cockpit — Dedicated domain and per-tenant JWT (Layer 7)

Each tenant accesses the Cockpit interface through a dedicated domain: client.odata.fr. The SSL certificate (Let's Encrypt) is issued for this domain. The authentication JWT is signed with a tenant-specific secret key and contains the tenant_id in its claims.

The nginx middleware validates the JWT before routing the request. An attempt to access client-b.odata.fr with tenant A's JWT is rejected at the reverse proxy level — before the request even reaches the API. The domain itself constitutes an isolation boundary: a tenant cannot guess another tenant's subdomain (the names are UUIDs or opaque identifiers).

4.2 Wildcard DNS and namespaced NATS (Layer 8)

Layer 8 operates at the inter-service communication level:

Wildcard DNS. The *.odata.fr record points to the infrastructure. Each subdomain resolves, but the application server filters unregistered domains. A tenant cannot create an arbitrary subdomain — the DNS record is controlled by the infrastructure.

Namespaced NATS. The NATS message bus uses subjects prefixed by the tenant:

The NATS ACLs are configured so that tenant A's credentials can only publish or subscribe to subjects tenant.a1b2c3d4.*. The NATS server enforces these ACLs at the protocol level — a client cannot bypass the namespacing.

4.3 Port map — No service on 0.0.0.0 (Layer 9)

Layer 9 is the most physical: the documented port map. No internal service listens on 0.0.0.0. Each service is bound to 127.0.0.1 with an explicit port. The firewall (UFW, default deny policy) blocks all incoming traffic that is not explicitly allowed. This layer is documented in detail in Section 5.