Minden kérésnél és feladatnál határozza meg a szervezet megbízható kontextusát, a szűrést központilag, az adatrétegben kényszerítse ki, és ugyanezt a kontextust vigye át a gyorsítótárba, a fájlokba, a keresésbe és a sorokba. Az adminisztrációt, az exportot és a támogatást auditálja, és automatikusan tesztelje az ügyfelek közötti hozzáférési kísérleteket.
A multitenant webalkalmazás több ügyfélszervezetet szolgál ki egy közös platformon. A legsúlyosabb kockázat az, hogy egy felhasználó vagy folyamat egy másik ügyfél adatait látja vagy módosítja. A hiba nem feltétlenül csak az adatbázis-lekérdezésben van. A kontextus elveszhet a gyorsítótárban, egy fájlban, exportban, keresési indexben, sorban vagy adminisztrátori eszközben.
A biztonságos tervezéshez egyértelmű bérlőazonosítás, az elkülönítés minden rétegben történő kikényszerítése és negatív forgatókönyvek tesztelése szükséges. A fizikai elkülönítés mértéke a kockázattól, a szerződéses követelményektől, a mennyiségtől és az üzemeltetés összetettségétől függ. Egyetlen adatbázis nem automatikusan veszélyes, és egy külön adatbázis önmagában nem szünteti meg az identitáskezelés vagy az adminisztráció hibáit.
Válassza ki a bérlői és tagsági modellt
Határozza meg, mi a bérlő: cég, munkaterület, projekt vagy más biztonsági határ. Egy felhasználó egy vagy több szervezethez tartozhat, és mindegyikben más szerepköre lehet. Az aktív kontextusnak érthetőnek kell lennie a felületen és a szerveren is. A szervezetváltás nem hagyhat régi adatokat a képernyőn vagy a cache-ben.
A tagság, a meghívás, a deaktiválás és a tulajdonjog átruházása auditált doménfolyamatok. A bérlőt ne csupán a kliens által küldött azonosítóból vezesse le. A szerver összekapcsolja azt az ellenőrzött identitással és az aktuális tagsággal. Saját domain vagy aldomain esetén ellenőrizze, hogy az útválasztás ugyanannak a biztonságos kontextusnak felel-e meg.
Kényszerítse ki az izolációt az adatrétegben
Minden rekord hordozza a bérlő (tenant) azonosítóját, vagy olyan struktúrához tartozik, amelyből ez biztonságosan levezethető. A lekérdezéseknek ezt a határt központilag kell alkalmazniuk, nem szabad a fejlesztő emlékezetére hagyatkozniuk minden egyes endpointnál. Az adatbázis-mechanizmusok további védelmi réteget adhatnak, de konfigurációjuk és a privilegizált fiókok saját teszteket igényelnek.
Íráskor ellenőrizze, hogy minden kapcsolódó objektum ugyanahhoz a bérlőhöz (tenant) tartozik-e. Egy megrendelési tételben szereplő idegen azonosító nem mehet át csak azért, mert magát a megrendelést a felhasználó birtokolja. Az egyedi kulcsok, a párosítás és az aggregációk gyakran igénylik a bérlő szerinti hatókört. A migrációknak a régi rekordoknál is meg kell őrizniük az azonosítást.
- kötelező bérlőazonosító minden rekordnál
- központi szűrés és jogosultságkezelés
- objektumok közötti kapcsolatok ellenőrzése
- megfelelő adatbázis-szintű védelmi réteg
Vigye át a kontextust a gyorsítótárba, a sorokba és a fájlokba
A gyorsítótárkulcsnak tartalmaznia kell a bérlőt és az egyéb releváns hatókört. Ellenkező esetben az első ügyfél olyan értéket tölthet be, amelyet a második kap meg. Ugyanez a szabály érvényes a számításokra, a rate limitre és a keresési eredményekre. Érvénytelenítéskor csak a megfelelő teret törölje, és a határt ne ellenőrizetlen bemenetből vezesse le.
A sorban lévő üzenet tartalmazza a bérlőt, a szereplő identitását és a feladat végrehajtására vonatkozó biztonságos jogosultságot. A feldolgozó újra ellenőrzi a kontextust, mert a tagság időközben megváltozhatott. A fájlokat izolált útvonalon tárolja, és engedélyezett letöltési móddal tegye elérhetővé. Egy nyilvánosan kitalálható URL nem lehet a dokumentum egyetlen védelme.
Védje az adminisztrációt, a támogatást és az exportokat
A globális adminisztráció nagyobb kockázatot jelent, mint egy átlagos fiók. Korlátozza a jogosult személyek számát, alkalmazzon erős hitelesítést, és auditálja az aktív ügyfél váltását. Az ügyfélszolgálat csak a szükséges nézetet és időben korlátozott, a felhasználó nevében történő eljárást kapja meg. A felület láthatóan jelzi, melyik bérlőben (tenantban) történik a beavatkozás.
Az export, a biztonsági mentés és az analitikai adattárház megkerülheti az alkalmazás képernyőinek védelmét. Minden kimenetet szűrjön jogosultság szerint, és küldés előtt ellenőrizze a terjedelmét. A hosszabb ideig generált export letöltéskor ismét ellenőrzi a hozzáférést. Az ügyfélkapcsolat megszűnésekor határozza meg az exportot, a megőrzést és a törlést – a másolatokat is beleértve – a szerződések és szakmai értékelés alapján.
Tesztelje az izolációt automatikusan és üzemeltetési szinten is
A tesztkészlet legalább két, hasonló azonosítókkal rendelkező szervezetet hoz létre, és kipróbálja az olvasást, a szerkesztést, a keresést, az exportot, a mellékleteket, az API-t és a sorokat is a határon átnyúlóan. Változtassa meg az azonosítót az URL-ben, a kérés törzsében, a fejlécben és a cache-ben. Ellenőrizze a szervezeti adminisztrátort és a globális ügyfélszolgálatot is. Minden új adatút egy negatív tesztet von maga után.
A naplókban kövesse nyomon az elutasított kísérleteket és a szokatlan váltásokat, érzékeny tartalom tárolása nélkül. Az incidenskezelési eljárás képes elkülöníteni a bérlőt, megőrizni a bizonyítékokat és meghatározni egy esetleges adatszivárgás terjedelmét. Architekturális változás esetén ismételje meg a fenyegetésmodellezést. Az izoláció az egész rendszer folyamatos tulajdonsága, nem egyszeri szűrő az adatbázisban.
- idegen azonosítók minden nyilvános API-felületen
- másik bérlő adataival feltöltött gyorsítótár
- export és a tagság változása után elérhető fájl
- aszinkron feladat érvénytelen szervezeti kontextussal
- rossz ügyfélre átkapcsolt globális támogatás
Gyakori kérdések
Minden ügyfélnek saját adatbázis kell?
Nem mindig. A modell a kockázattól, a követelményektől, a mennyiségtől és az üzemeltetéstől függ. A közös adatbázis következetes izolációt igényel; a különálló adatbázis pedig helyes útválasztást, identitáskezelést, frissítéseket és monitorozást.
Biztonsági határ a bérlő számára az aldomain?
Hasznos bemenet az útválasztáshoz, de a szervernek a kontextust ellenőrzött identitáshoz és tagsághoz kell kötnie. A hosztnév önmagában nem helyettesíti az egyes erőforrások jogosultság-ellenőrzését.
Hogyan teszteljük az ügyfelek közötti adatszivárgást?
Hozzon létre két elkülönített szervezetet, és automatikusan próbálja ki az idegen azonosítókat minden felületen, beleértve az exportot, a fájlokat, a keresést, a gyorsítótárat és az aszinkron feladatokat is, ne csak egyetlen képernyőn.
Források és további olvasnivaló
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.
