Při každém požadavku a úloze určete důvěryhodný kontext organizace, filtrování vynucujte centrálně v datové vrstvě a stejný kontext přenášejte do cache, souborů, vyhledávání a front. Administraci, export a podporu auditujte a automaticky testujte pokusy o přístup napříč klienty.
Multitenantní webová aplikace obsluhuje více zákaznických organizací na společné platformě. Nejzávažnějším rizikem je, že uživatel nebo proces uvidí či změní data jiného klienta. Chyba nemusí být pouze v databázovém dotazu. Kontext se může ztratit v cache, souboru, exportu, vyhledávacím indexu, frontě nebo administrátorském nástroji.
Bezpečný návrh vyžaduje jednoznačnou identitu tenanta, vynucení izolace ve všech vrstvách a testy negativních scénářů. Míra fyzického oddělení závisí na riziku, smluvních požadavcích, objemu a provozní složitosti. Jedna databáze není automaticky nebezpečná a samostatná databáze sama o sobě neodstraní chyby v identitě či administraci.
Zvolte model nájemce a členství
Definujte, co je nájemník: firma, pracovní prostor, projekt nebo jiná bezpečnostní hranice. Uživatel může patřit do jedné nebo více organizací a mít v každé jinou roli. Aktivní kontext musí být srozumitelný v rozhraní i na serveru. Změna organizace nesmí ponechat stará data na obrazovce nebo v cache.
Členství, pozvání, deaktivace a převod vlastnictví jsou doménové procesy s auditem. Nájemce neodvozujte jen z ID zaslaného klientem. Server jej propojí s ověřenou identitou a aktuálním členstvím. U vlastní domény nebo subdomény ověřte, že směrování odpovídá stejnému bezpečnému kontextu.
Vynucujte izolaci v datové vrstvě
Každý záznam nese identitu nájemce (tenanta) nebo patří do struktury, z níž ji lze bezpečně odvodit. Dotazy musí tuto hranici uplatňovat centrálně, nikoli spoléhat na paměť vývojáře u každého endpointu. Databázové mechanismy mohou přidat obrannou vrstvu, ale jejich konfigurace a privilegované účty potřebují vlastní testy.
Při zápisu ověřte, že všechny související objekty patří stejnému tenantovi. Cizí ID v položce objednávky nesmí projít jen proto, že samotnou objednávku uživatel vlastní. Jedinečné klíče, párování a agregace často potřebují rozsah tenanta. Migrace musí zachovat identitu i u starých záznamů.
- povinná identita nájemce u každého záznamu
- centrální filtrování a autorizace
- kontrola vztahů napříč objekty
- přiměřená databázová obranná vrstva
Přeneste kontext do cache, front a souborů
Klíč cache musí zahrnovat tenanta a další relevantní rozsah. Jinak může první klient naplnit hodnotu, kterou pak dostane druhý. Stejné pravidlo platí pro výpočty, rate limit a výsledky vyhledávání. Při invalidaci odstraňte pouze správný jmenný prostor a hranici neodvozujte z neověřeného vstupu.
Zpráva ve frontě obsahuje nájemce (tenanta), identitu aktéra a bezpečné oprávnění k provedení úlohy. Worker kontext znovu ověří, protože členství se mohlo změnit. Soubory ukládejte s izolovanou cestou a autorizovaným způsobem stahování. Veřejně uhodnutelná URL nesmí být jedinou ochranou dokumentu.
Chraňte administraci, podporu a exporty
Globální administrace představuje vyšší riziko než běžný účet. Omezte počet oprávněných osob, používejte silné ověření a auditujte změnu aktivního klienta. Podpora má dostat jen potřebný pohled a časově omezené jednání jménem uživatele. Rozhraní viditelně označí, ve kterém tenantovi se zásah provádí.
Export, záloha a analytický sklad mohou obejít ochranu aplikačních obrazovek. Každý výstup filtrujte podle oprávnění a před odesláním zkontrolujte rozsah. Déle generovaný export znovu ověří přístup při stažení. Při ukončení spolupráce s klientem definujte export, retenci a výmaz včetně kopií podle smluv a odborného posouzení.
Testujte izolaci automaticky i provozně
Testovací sada vytvoří nejméně dvě organizace s podobnými identifikátory a zkouší čtení, úpravu, vyhledávání, export, přílohu, API i frontu napříč hranicí. Změňte ID v URL, těle, hlavičce a cache. Ověřte administrátora organizace i globální podporu. Každá nová datová cesta přidává negativní test.
V logech sledujte zamítnuté pokusy a neobvyklé přepínání, aniž byste ukládali citlivý obsah. Postup pro incidenty umožní izolovat nájemce (tenanta), zachovat důkazy a určit rozsah možného úniku. Při architektonické změně zopakujte model hrozeb. Izolace je průběžná vlastnost celého systému, nikoli jednorázový filtr v databázi.
- cizí ID v každém veřejném API rozhraní
- cache naplněná údaji jiného nájemníka
- export a soubor dostupný po změně členství
- asynchronní úloha s neplatným kontextem organizace
- globální podpora přepnutá do nesprávného klienta
Časté dotazy
Potřebuje každý klient vlastní databázi?
Ne vždy. Model závisí na riziku, požadavcích, objemu a provozu. Společná databáze potřebuje důslednou izolaci; samostatná databáze zase správné směrování, identity, aktualizace a monitoring.
Je subdoména bezpečnostní hranicí nájemce?
Je užitečným vstupem pro směrování, ale server musí kontext propojit s ověřenou identitou a členstvím. Samotný název hostitele nenahrazuje autorizaci každého zdroje.
Jak testovat únik mezi klienty?
Vytvořte dvě izolované organizace a automaticky zkoušejte cizí ID ve všech rozhraních včetně exportu, souborů, vyhledávání, cache a asynchronních úloh, nejen na jedné obrazovce.
Zdroje a další čtení
Adam Antoni vyvíja weby, aplikácie a softvér na mieru. Prepája firemné systémy, automatizuje procesy a vytvára AI agentov. Pôsobí v Spišskej Novej Vsi a spolupracuje s firmami na celom Slovensku.
