Určte dôveryhodný kontext organizácie pri každej požiadavke a úlohe, filtráciu vynucujte centrálne v dátovej vrstve a rovnaký kontext prenášajte do cache, súborov, vyhľadávania a frontov. Administráciu, export a podporu auditujte a automaticky testujte pokusy o prístup naprieč klientmi.
Multitenant webová aplikácia obsluhuje viac zákazníckych organizácií v spoločnej platforme. Najzávažnejším rizikom je, že používateľ alebo proces uvidí či zmení dáta iného klienta. Chyba nemusí byť iba v databázovom dotaze. Kontext sa môže stratiť v cache, súbore, exporte, vyhľadávacom indexe, fronte alebo administrátorskom nástroji.
Bezpečný návrh potrebuje jednoznačnú identitu nájomníka, vynútenie izolácie vo všetkých vrstvách a testy negatívnych scenárov. Miera fyzického oddelenia závisí od rizika, zmluvných požiadaviek, objemu a prevádzkovej zložitosti. Jedna databáza nie je automaticky nebezpečná a samostatná databáza sama neodstráni chyby v identite či administrácii.
Zvoľte model nájomníka a členstva
Definujte, čo je nájomník: firma, pracovný priestor, projekt alebo iná bezpečnostná hranica. Používateľ môže patriť do jednej alebo viacerých organizácií a mať v každej inú rolu. Aktívny kontext musí byť zrozumiteľný v rozhraní aj na serveri. Zmena organizácie nesmie ponechať staré dáta v obrazovke alebo cache.
Členstvo, pozvanie, deaktivácia a prevod vlastníctva sú doménové procesy s auditom. Neodvodzujte nájomníka iba z ID poslaného klientom. Server ho spojí s overenou identitou a aktuálnym členstvom. Pri vlastnej doméne alebo subdoméne overte, že smerovanie zodpovedá rovnakému bezpečnému kontextu.
Vynucujte izoláciu v dátovej vrstve
Každý záznam nesie identitu nájomníka alebo patrí do štruktúry, z ktorej sa dá bezpečne odvodiť. Dotazy musia túto hranicu aplikovať centrálne, nie spoliehať sa na pamäť vývojára pri každom endpoint-e. Databázové mechanizmy môžu pridať obrannú vrstvu, ale ich konfigurácia a privilegované účty potrebujú vlastné testy.
Pri zápise overte, že všetky súvisiace objekty patria rovnakému nájomníkovi. Cudzie ID v položke objednávky nesmie prejsť iba preto, že samotnú objednávku používateľ vlastní. Jedinečné kľúče, párovanie a agregácie často potrebujú rozsah nájomníka. Migrácie musia zachovať identitu aj pri starých záznamoch.
- povinná identita nájomníka pri každom zázname
- centrálne filtrovanie a autorizácia
- kontrola vzťahov naprieč objektmi
- primeraná databázová obranná vrstva
Preneste kontext do cache, frontov a súborov
Cache kľúč musí zahŕňať nájomníka a ďalší relevantný rozsah. Inak môže prvý klient naplniť hodnotu, ktorú dostane druhý. Rovnaké pravidlo platí pre výpočty, rate limit a výsledky vyhľadávania. Pri invalidácii odstráňte iba správny priestor a neodvoďte hranicu z neovereného vstupu.
Správa vo fronte obsahuje nájomníka, identitu aktéra a bezpečné oprávnenie vykonať úlohu. Pracovník kontext znovu overí, pretože členstvo sa mohlo zmeniť. Súbory ukladajte s izolovanou cestou a autorizovaným spôsobom sťahovania. Verejne uhádnuteľná URL nesmie byť jedinou ochranou dokumentu.
Chráňte administráciu, podporu a exporty
Globálna administrácia predstavuje vyššie riziko než bežný účet. Obmedzte počet oprávnených osôb, používajte silné overenie a auditujte zmenu aktívneho klienta. Podpora má dostať iba potrebný pohľad a časovo obmedzené konanie v mene používateľa. Rozhranie viditeľne označí, v ktorom nájomníkovi sa zásah vykonáva.
Export, záloha a analytický sklad môžu obísť ochranu aplikačných obrazoviek. Každý výstup filtrujte podľa oprávnenia a pred odoslaním skontrolujte rozsah. Dlhšie generovaný export znovu overí prístup pri stiahnutí. Pri ukončení klienta definujte export, retenciu a vymazanie vrátane kópií podľa zmlúv a odborného posúdenia.
Testujte izoláciu automaticky aj prevádzkovo
Testovacia sada vytvorí najmenej dve organizácie s podobnými identifikátormi a skúša čítanie, úpravu, vyhľadávanie, export, prílohu, API aj front naprieč hranicou. Zmeňte ID v URL, tele, hlavičke a cache. Overte administrátora organizácie aj globálnu podporu. Každá nová dátová cesta pridáva negatívny test.
V logoch sledujte zamietnuté pokusy a neobvyklé prepínanie bez ukladania citlivého obsahu. Incidentný postup dokáže izolovať nájomníka, zachovať dôkazy a určiť rozsah možného úniku. Pri architektonickej zmene zopakujte hrozbový model. Izolácia je priebežná vlastnosť celého systému, nie jednorazový filter v databáze.
- cudzie ID v každom verejnom API rozhraní
- cache naplnená údajmi iného nájomníka
- export a súbor dostupný po zmene členstva
- asynchrónna úloha s neplatným kontextom organizácie
- globálna podpora prepnutá do nesprávneho klienta
Časté otázky
Potrebuje každý klient vlastnú databázu?
Nie vždy. Model závisí od rizika, požiadaviek, objemu a prevádzky. Spoločná databáza potrebuje dôslednú izoláciu; samostatná databáza zasa správne smerovanie, identity, aktualizácie a monitoring.
Je subdoména bezpečnostná hranica nájomníka?
Je užitočný vstup do smerovania, ale server musí kontext spojiť s overenou identitou a členstvom. Samotný názov hostiteľa nenahrádza autorizáciu každého zdroja.
Ako testovať únik medzi klientmi?
Vytvorte dve izolované organizácie a automaticky skúšajte cudzie ID vo všetkých rozhraniach vrátane exportu, súborov, vyhľadávania, cache a asynchrónnych úloh, nielen na jednej obrazovke.
Zdroje a ďalšie čítanie
Web developer zo Spišskej Novej Vsi. Venuje sa WordPressu, WooCommerce, vlastným pluginom, API integráciám, webovým aplikáciám a praktickým AI automatizáciám.
