Multi-tenant architektura: jeden systém, oddělené firmy

01Firma v systému potřebuje vlastní hranici

Jedna přihlášená osoba nemusí představovat jednu firmu. Účetní může pracovat pro několik společností, zaměstnanec může patřit do více pracovních prostorů. Tenant je vymezená skupina zákazníka nebo organizace, pro kterou aplikace odděluje data a pravidla. Microsoft popisuje tento rozdíl výslovně: tenant a uživatel nejsou stejný pojem.

Nejprve si ujasněte, čemu tato hranice odpovídá ve vašem produktu. Je tenant účet zákaznické firmy, samostatná provozovna, nebo skupina společností? Volba ovlivní fakturaci, oprávnění i sdílení záznamů. Sjednoťte ji s obchodním zadáním, než vývojáři vytvoří první tabulky a registrační formulář.

Představte si český systém pro správu servisních zakázek. Každá firma spravuje zákazníky a techniky, ale několik společností využívá stejnou aplikaci. Návštěvník má vidět jen zakázky firem, v nichž má odpovídající členství. Název společnosti na obrazovce nestačí: hranice musí platit při čtení, úpravě, exportu i odesílání upozornění.

Začněte scénáři, které mohou hranici komplikovat. Konzultant se přepíná mezi zákazníky, centrála potřebuje společný přehled a platformní podpora řeší problém jedné firmy. Každý takový přístup musí mít výslovné oprávnění. Výjimka pro správce nesmí být skrytou zkratkou, kterou používají běžné požadavky.

02Vyberte úroveň sdílení podle potřeby

Multi-tenant neznamená jedinou povinnou databázovou architekturu. Aplikace může sdílet tabulky s identifikátorem firmy, používat samostatná schémata nebo oddělené databáze. Část zákazníků může mít vyhrazené prostředky. Dokumentace Azure popisuje sdílení i oddělení dat a jejich provozní kompromisy.

Porovnejte také obnovu jedné firmy, umístění dat a náklady správy. Levnější první nasazení může vyžadovat více práce při pozdějším oddělení velkého zákazníka. Samostatná databáze zase nevytvoří bezpečnostní hranici, pokud všechny provozní cesty používají jeden neomezený účet a aplikace snadno zamění připojení.

Dokumentujte důvod volby a okolnost, při níž ji přehodnotíte. Například zákazník potřebuje odlišné podmínky obnovy nebo jeho zátěž začíná ovlivňovat ostatní. Architekturu vybírejte pro skutečný provozní model. Samotný plán „jednou stovky firem“ neříká nic o počtu souběžných úloh, objemu příloh ani citlivosti údajů.

03Přihlášení ještě nepotvrzuje přístup k firmě

Po ověření identity potřebujete určit, za kterou firmu člověk jedná a co v ní smí udělat. Identifikátor firmy zaslaný z prohlížeče lze použít jako výběr, nikoli jako důkaz oprávnění. OWASP doporučuje ověřit členství či pověření na serveru a přenášet tento ověřený kontext do dalších částí systému.

V praktickém zadání popište například čtení zakázky, změnu ceny a export zákazníků jako samostatná oprávnění. Člen firmy nemá automaticky právo na všechny úkony. Zvlášť upravte odchod zaměstnance, odebrání role a přepnutí organizace. Dříve platné oprávnění nemusí zůstat platné pro pozdější operaci.

V databázi může další kontrolní vrstvu tvořit zabezpečení řádků, označované RLS. PostgreSQL upozorňuje, že superuživatelé a role s BYPASSRLS tento mechanismus obcházejí; vlastníci tabulek jej běžně obcházejí také, pokud není použito příslušné vynucení. Nestačí tedy pouze vytvořit pravidlo a prohlásit izolaci za dokončenou.

Požadujte test, který použije platný účet jedné firmy a zkusí pracovat se záznamem jiné. Stejnou kontrolu proveďte pro soubory a hromadné operace. Smyslem není jen test správného průchodu formulářem. Důležitý je prokazatelný výsledek při chybném či úmyslně změněném požadavku.

04Hranici udržte také mimo databázi

Zakázka může pokračovat exportem, generováním dokumentu nebo odesláním e-mailu na pozadí. Do návrhu proto zahrňte celé zpracování, nejen první API požadavek. U každé úlohy popište vlastníka dat, příjemce a povolený účel. Rozhodnutí nesmí záviset na tom, které pracovní vlákno zrovna úkol provádí.

Rozlišení firmy potřebují také chráněné výsledky v cache a souborová úložiště. OWASP výslovně doporučuje tenantový rozsah v klíčích cache, když výsledek závisí na firmě. U veřejných společných hodnot může být sdílení záměrné. Nezaměňujte tedy zákaznický export s obecně dostupným číselníkem.

Pro servisní příklad navrhněte kontrolní trasu: technik založí zakázku, systém připraví PDF a zákazník dostane odkaz. V každém kroku ověřte, že nedošlo k záměně firmy a dokument nemá širší dostupnost, než potřebuje. Do testu přidejte dvě firmy s podobnými názvy a stejným číslem interní zakázky.

Zahrňte do kontroly také vyhledávání a náhledy příloh. I když detail cizí zakázky přístup odmítne, našeptávač nesmí prozradit její název, kontakt nebo cenu. Vývojáři mají znát všechny cesty, kterými aplikace záznam čte. Podobně prověřte oznámení v mobilní aplikaci a odkazy zasílané e-mailem. Zákazník potřebuje konzistentní výsledek napříč funkcemi, nikoli různou úroveň ochrany podle použité obrazovky.

Podpora má používat dohledatelný a omezený přístup. Zaznamenejte důvod zásahu, rozsah a osobu, která jej provedla. Nezpřístupňujte zákaznická data v běžném souhrnném logu jen proto, že je tak snazší ladění. Ochrana celého provozu navazuje na bezpečnost dat v systému na míru.

05Výkon plánujte podle chování jednotlivých firem

Počet registrovaných společností je slabým popisem kapacity. Jedna firma může importovat tisíce příloh, jiná několik hodin neprovede žádný úkon. Zapište očekávané náročné operace, jejich souběh a hranice přijatelného čekání. Výkonnostní zkouška má vycházet z těchto scénářů, ne z náhodného počtu přihlášení.

Sdílené prostředky mohou přenášet zátěž jednoho zákazníka na další. Provozní rozhodnutí zahrnuje limity náročných operací, řazení úloh a případné oddělení kapacity. Určete, co uživatel uvidí při dosažení limitu a kdo dostane upozornění. Tichý neúspěch importu je pro zákazníka jiný problém než srozumitelně odložená práce.

Měřte dobu odpovědi, chyby a spotřebu důležitých operací v souvislosti s firmou, které patří. Celkový průměr může vypadat dobře, i když konkrétní zákazník opakovaně čeká. Současně potřebujete souhrnný pohled na infrastrukturu. Oba pohledy podporují odlišná rozhodnutí a mají mít srozumitelnou vazbu.

Neuvádějte v nabídce počet obsloužených firem bez podmínek. Užitečnější je popis ověřené zátěže, prostředí a omezení. Stovky klidných zákazníků nejsou stejný úkol jako několik firem s velkými dávkovými výpočty. Cena provozu také zahrnuje dohled, aktualizace a práci při výjimkách, nikoli pouze server.

06Životní cyklus firmy připravte před růstem

Založení zákazníka zahrnuje více než nový řádek s názvem. Potřebujete nastavení, první oprávněnou osobu, případná data a pravidla tarifu. Navrhněte opakovatelný postup, který lze dokončit či bezpečně opravit po přerušení. Ručně sestavené zákaznické prostředí je obtížné později kontrolovat a aktualizovat.

Počítejte s pozastavením, změnou tarifu, přesunem a ukončením služby. Určete, které operace mohou pokračovat během přechodu, co se stane s rozpracovanou úlohou a jak se ověří výsledný stav. Pro firmu je důležité například to, zda po změně tarifu nepřestane být dostupná starší příloha bez předchozí dohody.

Aktualizace aplikace a databázových struktur musí respektovat zákazníky, jejichž změna doběhne později. Připravte plán přerušení, pokračování a ověření výsledku. Nová povinná položka nesmí bez přípravy zneplatnit staré záznamy. V testovacím prostředí proto zkuste různé stavy zákazníka a přerušení operace. U každé změny zapište, zda lze bezpečně vrátit aplikaci, data, nebo obojí. Tyto otázky patří do plánu vydání dříve než termín nasazení.

Obnovu z datové zálohy vyzkoušejte pro konkrétní firmu. Pokud záloha obsahuje i jiné zákazníky, postup nesmí při obnově odhalit jejich údaje nebo přepsat aktuální data ostatních. Předem dohodněte cíle obnovy a výsledek zkoušky zaznamenejte. Samotná informace „zálohujeme denně“ o použitelnosti tohoto scénáře mnoho neříká.

Při ukončení služby potřebuje zákazník čitelný export a správce doložený postup odebrání přístupů. Mazání a uchovávání musí odpovídat dohodnutým i zákonným požadavkům. Rozlišujte aktivní data, logy a zálohy. Univerzální slib okamžitého odstranění všech kopií není vhodným náhradním řešením chybějícího návrhu.

07Pilot má ověřit hranice i běžnou práci

Začněte omezenou funkční částí pro několik odlišných modelových firem. Jedna má běžné zakázky, druhá mnoho příloh, třetí uživatele působícího i jinde. Jde o autorský návrh testovacích situací. Skutečné počty a objemy stanovte podle produktu a očekávaného provozu.

1. Určete význam tenantu a potřebné výjimky.
2. Vyberte datovou hranici a role provozních účtů.
3. Ověřte cizí záznamy, soubory a úlohy na pozadí.
4. Vyzkoušejte obnovu, zatížení a ukončení zákazníka.

Po pilotu rozhodněte podle skutečných nedostatků. Nepřidávejte automaticky další vrstvy jen proto, že znějí pokročile. Důležitá je doložená hranice dat, zvládnutelná údržba a jasný postup výjimek. Další přípravu produktu můžete spojit s plánováním vývoje SaaS aplikace.

08Časté otázky k multi-tenant architektuře