Sovereign Multi-Tenant IAM: Tenant Isolation and Privilege Separation

Sovereign multi-tenant IAM, in the context of shared on-premises infrastructure serving multiple legal entities, refers to the set of identity, access and cryptographic controls that ensure each tenant’s data and administrative domain remain isolated from every other tenant and from the platform operator itself. For government bodies, law firms, financial institutions and healthcare organisations that share a sovereign collaboration stack, this is not an abstract architectural preference: it is the precondition for lawful processing under the GDPR, for incident-detection obligations under NIS-2, and for operational resilience requirements under DORA.

Why Shared Infrastructure Creates Structural Legal Risk

When multiple legal entities share the same Nextcloud deployment, hypervisor cluster or storage array, the boundaries between their data are defined not by physical separation but by software controls. Those controls must be provably enforceable, not just policy-stated.

The IBM Cost of a Data Breach Report 2023 found that the average breach cost reached USD 4.45 million, the highest ever recorded in the study. That figure rises substantially when the breach involves regulated health, financial or legal data. More structurally, the Verizon Data Breach Investigations Report 2022 found that 82 percent of breaches involved a human element including privilege misuse and stolen credentials, precisely the attack surface that multi-tenant IAM must close.

GDPR Article 32 requires pseudonymisation and encryption as explicit technical measures. The European Data Protection Board, in its Guidelines 04/2019 on Article 25, states: “Pseudonymisation and encryption are not optional add-ons; they are the technical and organisational measures that Article 32 explicitly requires to demonstrate an appropriate level of security.” In a shared environment, that means per-tenant encryption keying, not a single operator-controlled key.

Cryptographic Tenant Isolation: The Architectural Baseline

Policy controls alone cannot satisfy auditors or DPOs. A sovereign operator must implement cryptographic separation so that gaining access to the storage layer does not yield readable tenant data.

The practical implementation involves three layers. First, each tenant’s data at rest is encrypted with a tenant-specific key managed in a dedicated key management service (KMS) or hardware security module (HSM) to which the platform operator does not hold decryption rights. The tenant’s identity provider, typically a Keycloak realm or an equivalent OpenID Connect issuer, controls key release. Second, data in transit between tenant workloads and the platform is authenticated and encrypted per session using TLS certificates scoped to the tenant’s namespace. Third, at the hypervisor layer, memory encryption technologies such as AMD SEV or Intel TDX prevent a privileged host process from reading guest memory contents, adding a hardware root of trust to the software isolation model.

Role-Based and Attribute-Based Access Control: Preventing Silent Super-Admin Access

A sovereign platform’s IAM design must ensure that no single role, including the platform super-administrator, can traverse tenant boundaries without leaving a verifiable trace, and ideally without a cryptographic capability to decrypt what is found.

ISO/IEC 27001 Annex A.9 specifies access-control requirements including user registration, privilege management and periodic review of access rights. Translating this into a multi-tenant architecture means maintaining strictly separate RBAC hierarchies per tenant namespace: a Nextcloud group administrator for Tenant A has no visibility of Tenant B’s groups, shares or audit logs.

ABAC adds a second enforcement layer that operates at the data classification level rather than the role level. For example, an attribute policy can specify that any file tagged with the classification label “legally privileged” may only be accessed by a user whose identity token contains both the correct tenant claim and a secondary claim confirming completion of the relevant matter authorisation workflow. These policies can be enforced by Open Policy Agent or a comparable policy engine at the API gateway level, independently of the application’s own permission checks.

To make the guarantee auditable to each tenant’s DPO, every access decision, whether permitted or denied, must be logged to an append-only audit store that the tenant can query independently and that the platform operator cannot modify. The ENISA Threat Landscape 2023 found that access-control failures remained among the top three root causes of significant incidents, reinforcing that auditable enforcement is not a compliance formality but an operational necessity.

Federated Identity: OIDC and SAML Patterns for Per-Tenant MFA Enforcement

Each tenant in a sovereign multi-tenant environment must be able to operate its own identity provider, enforce its own MFA policy and authenticate its users without any cross-tenant token visibility.

The standard pattern uses OpenID Connect (OIDC) with a separate Keycloak realm per tenant. Each realm has its own issuer URL, its own client registrations and its own authentication flows including conditional MFA policies. The platform’s API gateway validates the issuer claim in every presented token and routes the request exclusively to the corresponding tenant’s namespace. A token issued by the realm of Tenant A is structurally rejected by the namespace of Tenant B at the gateway level, before any application logic is reached.

SAML 2.0 federation is the appropriate pattern where a tenant’s existing enterprise identity provider, such as Active Directory Federation Services or a government eID gateway, does not support OIDC natively. In this model, Keycloak acts as a SAML service provider that brokers assertions into OIDC tokens, preserving the tenant’s existing MFA enforcement and attribute structure while presenting a uniform interface to the platform.

NIS-2 Article 21 explicitly mandates multi-factor authentication and access control as minimum security measures. For a DORA audit, the same controls must be demonstrably tested: auditors expect evidence of issuer-confusion attack tests, token substitution test cases and session fixation checks, all documented in penetration test reports that reference the specific realm configuration tested.

GDPR Article 26 and Contractual Boundaries Between Operator and Tenant

GDPR Article 26 governs joint controllers: parties that together determine the purposes and means of processing. In a shared sovereign infrastructure context, the legal characterisation of the platform operator depends precisely on what the operator can technically do with tenant data.

A platform operator that performs aggregate security monitoring will process tenant event data to detect anomalies and meet NIS-2 incident-detection obligations. That specific processing activity creates a joint-controller relationship for the monitoring purpose, even if the underlying file storage is purely processor territory. The Article 26 agreement must therefore specify: which processing activities are within joint-controller scope; each party’s responsibility for responding to data subject requests relating to those activities; the DPO contact details for both parties; and the breach notification obligations including who informs the supervisory authority when both parties are involved.

Per-Tenant Audit Trails and SIEM Architecture

A sovereign SIEM architecture for a multi-tenant environment must solve a structural contradiction: each tenant’s log data must be readable by that tenant’s security team but not by other tenants, while the platform operator needs aggregate visibility for NIS-2 incident detection without having access to tenant application content.

The solution is a two-tier log pipeline. At the first tier, application-level events (file access, permission changes, authentication events) are written to a per-tenant append-only log store, cryptographically signed with a key controlled by the tenant’s KMS. The tenant can verify the integrity of their own logs; the platform operator cannot modify them without the signature becoming invalid. At the second tier, infrastructure-level events (hypervisor CPU load, network flow anomalies, storage I/O patterns) are forwarded to a platform SIEM that receives only metadata stripped of application content. The platform’s security operations team detects behavioural anomalies and ransomware indicators at the infrastructure layer without ever processing tenant payload data.

NIS-2 Article 21 requires that essential and important entities implement measures for incident detection, handling and recovery. The two-tier architecture satisfies this obligation: the operator can detect and report a distributed denial-of-service attack affecting all tenants without needing to inspect individual tenant files to do so.

Privileged Access Management for Infrastructure Engineers

Infrastructure engineers performing maintenance on shared hypervisors or storage arrays represent the highest-privilege human attack surface in a multi-tenant environment. ENISA has stated: “Privileged access management is one of the most critical controls an organisation can implement; without it, every other security investment is undermined by the accounts that can bypass it.”

A just-in-time (JIT) PAM model addresses this by granting elevated access only for the duration of an approved, time-bounded maintenance task. The engineer requests access through a PAM gateway such as HashiCorp Vault, CyberArk or an equivalent open-source solution, receives a temporary credential scoped to the specific host and task type, and has every session command recorded in an immutable session log. At the end of the approved window, the credential is automatically revoked and reissued credentials become invalid.

For storage-layer maintenance, the JIT model must be combined with the cryptographic isolation described earlier: even with a valid storage-layer credential, the engineer sees only ciphertext unless the tenant’s KMS has separately authorised decryption for that session. The combination of JIT access, session recording and cryptographic separation means that the audit trail can demonstrate to any tenant’s DPO not only that the engineer was present but that no readable tenant data was accessible during the session.

ISO/IEC 27001 Annex A.9 requires periodic review of privileged access rights. In a JIT model, this review becomes structural rather than periodic: because standing privileges do not exist, there is nothing to accumulate and drift over time, which removes one of the most common findings in access-control audits.

FAQ

Can a Nextcloud super-administrator be technically prevented from reading tenant files in a shared deployment?

Yes, if tenant data is encrypted at the application layer with tenant-specific keys managed through a dedicated KMS that the platform operator does not control. Nextcloud’s server-side encryption can be combined with a tenant-controlled KMS so that decryption requires a key that only the tenant’s identity provider can authorise, making silent access by the operator cryptographically impossible rather than merely policy-prohibited.

What is the difference between RBAC and ABAC in a sovereign multi-tenant context, and which should I use?

Role-based access control grants permissions based on assigned roles, which is efficient but coarse-grained. Attribute-based access control evaluates dynamic attributes such as data classification, user location and time of day, enabling finer control for sensitive data. For regulated sectors, a layered model works best: RBAC for day-to-day operational roles, ABAC policies enforced at the data layer for anything classified as sensitive or regulated.

How does GDPR Article 26 apply when a sovereign platform operator and its tenants share the same hardware?

Article 26 applies when two or more controllers jointly determine the purposes and means of processing. A sovereign operator that merely provides isolated compute and storage, and has no technical ability to access tenant data, is more accurately characterised as a data processor under Article 28. However, if the operator also performs aggregate security monitoring that processes tenant event data, a joint-controller arrangement for that specific processing activity is necessary, with the Article 26 agreement specifying each party’s responsibilities including DPO contact points and breach notification duties.

How are federated OIDC tenants tested during a NIS-2 or DORA audit?

Auditors verify that each tenant’s OpenID Connect issuer URL is distinct and enforced at the gateway, that tokens from one issuer are rejected for resources in another tenant’s namespace, and that MFA enforcement is not bypassable by a platform-level account. Test cases include issuer-confusion attacks, token substitution and session fixation. Evidence for the audit should include Keycloak realm configuration exports, access-log samples showing rejected cross-tenant tokens and penetration test reports.

What is a just-in-time PAM model and why is it preferable for shared sovereign infrastructure?

Just-in-time PAM grants elevated privileges only for the duration of an approved maintenance task and revokes them automatically afterwards, as opposed to standing privileges that remain active indefinitely. For shared hypervisors and storage arrays, JIT means an infrastructure engineer receives a time-limited, task-scoped session with every command recorded in an immutable log. This limits the blast radius of a compromised administrator account and produces a precise audit trail that satisfies both NIS-2 Article 21 and ISO/IEC 27001 Annex A.9 requirements.