Multi-tenancy

• Tenant = Organizace
• Uživatel může patřit do více organizací.
• Aplikace běží pod aktivním kontextem organizace.

• Každý záznam vlastněný tenantem obsahuje organizationId (nebo ekvivalentní ownership pole).
• Všechny dotazy a zápisy jsou scoped na aktivní kontext organizace.
• Cross-tenant přístup je zakázaný, pokud není explicitně navržen (a auditovaný); ve výchozím stavu je mimo scope.

• Jedna Postgres databáze drží všechny tenanty.
• Logická izolace je vynucována pomocí:
• aplikační guard logiky (org kontext je povinný)
• scoping dotazů a ownership checků
• databázových omezení a indexačních strategií

Podle risk tolerance a roadmapy:

• Postgres politiky (např. row-level security) mohou přidat další vrstvu vynucení.
• Je to defense-in-depth doplněk, ne náhrada za správnost aplikace.

Protože uživatel může být členem více org:

• post-auth routing musí aktivní org vybrat nebo na ni uživatele vyzvat
• výběr org je perzistován bezpečným, serverem řízeným způsobem

• IDOR (Insecure Direct Object Reference): přístup k cizímu projektu hádáním ID.
• Leaky joins: joiny bez organizationId scoping.
• Leakage background jobů: exporty nebo async processing čtou/zapisují mimo org kontext.

• Indexování podle organizationId je klíčové pro predikovatelnost výkonu.
• Postupy backup/restore musí zachovat hranice tenantů a auditovatelnost.
• Support nástroje nikdy nesmí “nakukovat” cross-tenant bez explicitní autorizace a logování.