Cloud tenant isolation: Hiding other patients in the interface is not enough
Shared platforms need object-level authorisation and explicit isolation tests. Handle unexpected records without extending an exposure.
Revisión editorial:
El texto de este artículo está disponible en inglés en esta versión del sitio.
Contexto y fuentes
Multi-tenant services may share resources while logically separating customers. Every request must check whether a user can access the particular object. OWASP calls missing object-level checks Broken Object Level Authorization. [1]
Hidden buttons or hard-to-guess identifiers are not complete controls. Separate databases also do not guarantee safe search, export or support functions. Technical and organisational controls must work together. [1], [2]
Unauthorised exposure requires assessment. Article 33 GDPR governs regulator notification; Article 34 addresses affected people where high risk is likely. Notification conditions and automatic penalties are different matters. [3]
Alcance y límites
Multi-tenancy is not inherently unsafe, and this is not an allegation against a vendor. Do not test against other customers' production data without explicit authority.
Explicación sencilla
Fictional example: Two test tenants contain invented records. Authorised testers check searches, downloads and exports rather than approving isolation from the landing page alone.
Recomendaciones prácticas
Our recommendation: Ask for an explicit authorisation model and tenant-boundary test evidence. Cover APIs, background jobs, exports and administrative tools using an agreed scope and artificial records.
If unexpected real data appear, do not explore additional files. Stop unnecessary access and report securely to the provider and privacy team. Preserve only evidence needed under the agreed incident procedure; uncontrolled screenshots and forwarding can increase disclosure.