Huurderisolatie in multitenanttoepassing

Hallo allemaal! In dit hoofdstuk bouwen we voort op onze eerdere discussies over multitenant-onderwerpen. Als je de eerdere artikelen nog niet hebt gelezen, raden we aan om eerst daarmee te beginnen!

• Zijn multitenant-toepassingen = SaaS?
• Huurnemingsmodellen voor een multitenant-toepassing

Bij het bespreken van multitenanttoepassingen is het belangrijk om aan huurderisolatie te denken. Dit betekent dat de gegevens en bronnen van verschillende huurders gescheiden en veilig worden gehouden binnen een gedeeld systeem (bijvoorbeeld een cloudinfrastructuur of een multitenanttoepassing).

Het doel van huurderisolatie is ervoor te zorgen dat de gegevens en bewerkingen van elke huurder gescheiden en veilig blijven, zelfs wanneer ze dezelfde onderliggende bronnen gebruiken.

In een Software als een Dienst (SaaS)-scenario houdt huurderisolatie in dat er binnen het SaaS-raamwerk structuren worden gecreëerd die de toegang tot bronnen strikt reguleren. Dit voorkomt ongeoorloofde pogingen om toegang te krijgen tot de bronnen van een andere huurder.

Hoewel de uitleg abstract kan lijken, zullen we voorbeelden en belangrijke details gebruiken om de isolatiemindset verder uit te leggen.

Huurderisolatie staat niet haaks op de "gedeelde" mindset van multitenant#

Dat komt omdat huurderisolatie niet noodzakelijk een infrastructuurniveau-constructie is. In het rijk van multitenancy en isolatie beschouwen sommigen isolatie als een strikte scheiding tussen feitelijke infrastructuurbronnen. Dit leidt meestal tot een model waarin elke huurder aparte databases, computerinstanties, accounts of privé-clouds heeft. In gedeelde bronnenscenario's, zoals multitenanttoepassingen, kan isolatie worden bereikt als een logische constructie.

Huurderisolatie richt zich uitsluitend op het gebruik van de "huurder"-context om de toegang tot bronnen te beperken. Het evalueert de context van de huidige huurder en gebruikt die context om te bepalen welke bronnen toegankelijk zijn voor die huurder. Het past deze isolatie toe op alle gebruikers binnen die huurder. Elke poging om toegang te krijgen tot een huurderbron moet worden beperkt tot alleen die bronnen die bij die huurder horen.

Isolatie komt in verschillende niveaus#

Wanneer we begrijpen dat isolatie niet strikt is gekoppeld aan infrastructuurniveaus en geen duidelijke scheiding is tussen fysieke infrastructuur, leidt dit tot een conclusie als deze:

In plaats van isolatie te zien als een simpel "ja" of "nee," moet je het zien als een spectrum. Je kunt delen van je systeem opzetten om meer of minder geïsoleerd te zijn, afhankelijk van wat je nodig hebt.

Het onderstaande diagram illustreert dit spectrum van isolatie.

Authenticatie en autorisatie zijn niet gelijk aan "isolatie"#

Het gebruik van authenticatie en autorisatie om de toegang tot je SaaS-omgevingen te controleren is belangrijk, maar het is niet voldoende voor volledige isolatie. Deze mechanismen zijn slechts een deel van de beveiligingspuzzel.

Mensen vragen vaak of je algemene autorisatiesystemen en op rollen gebaseerde toegangscontrole kunt gebruiken om huurderisolatie te bereiken. Je kunt een multitenanttoepassing bouwen, maar je kunt niet zeggen dat je huurderisolatiestrategieën hebt bereikt en toegepast als beste praktijk. We raden het meestal niet aan omdat

Om het te illustreren, overweeg een situatie waarin je authenticatie en autorisatie hebt ingesteld voor je SaaS-systeem. Wanneer gebruikers inloggen, ontvangen ze een token met informatie over hun rol, die bepaalt wat ze in de toepassing kunnen doen. Deze aanpak verhoogt de beveiliging, maar zorgt niet voor isolatie.

Nu komt het probleem: zonder de "huurder"-context, zoals een huurder-ID, op te nemen om de toegang tot bronnen te beperken, zal het alleen vertrouwen op authenticatie en autorisatie niet voorkomen dat een gebruiker met de juiste rol toegang krijgt tot de bronnen van een andere huurder.

Dit is waar huurderisolatie in het spel komt. Het gebruikt huurder-specifieke identificatiemiddelen om grenzen vast te stellen, net zoals muren, deuren en sloten, die een duidelijke scheiding tussen huurders garanderen.

Identiteit in multitenancy apps#

We hebben huurderisolatie besproken, maar hoe zit het met identiteiten? Hoe bepaal je of je identiteiten "geïsoleerd" moeten zijn of niet?

Er is vaak verwarring rond het concept van "identiteitsisolatie." Het kan verwijzen naar situaties waarin één echte gebruiker twee identiteiten heeft in het algemeen begrip van mensen.

1. Beide identiteiten kunnen binnen één identiteitssysteem bestaan. Bijvoorbeeld, Sarah kan een persoonlijk e-mailadres hebben geregistreerd naast een zakelijk e-mailadres dat is verbonden via single sign-on (SSO).
2. Gebruikers hebben twee verschillende identiteiten binnen afzonderlijke identiteitssystemen, die volledig afzonderlijke producten vertegenwoordigen. Deze producten zijn totaal niet gerelateerd aan elkaar.

Soms worden deze scenario's "Identiteit geïsoleerd" genoemd. Toch helpt dit label mogelijk niet bij het maken van een beslissing.

In plaats van te bepalen of je "identiteitsisolatie" nodig hebt, overweeg of jij of een deel van je bedrijf of product aparte identiteitssystemen moet onderhouden. Dit antwoord kan je IAM-ontwerp (Identity and Access Management) sturen. Voor een kort antwoord betreffende een multitenanttoepassing,

In de meeste gevallen, in multitenanttoepassingen, worden identiteiten gedeeld terwijl de bronnen van elke huurder geïsoleerd zijn.

In multitenanttoepassingen worden identiteiten, in tegenstelling tot huurder-specifieke bronnen en gegevens, gedeeld onder meerdere huurders. Stel jezelf voor als de gebouwbeheerder; je zou niet twee aparte namenlijsten willen bijhouden om de identiteiten van je huurders te beheren.

Bij het streven naar huurderisolatie heb je mogelijk de steeds terugkerende nadruk op de term "organisatie" opgemerkt, vaak beschouwd als een beste praktijk voor het bouwen van multitenanttoepassingen.

Door gebruik te maken van het begrip "organisatie," kun je huurderisolatie bereiken in je multitenanttoepassing terwijl je een uniform identiteitssysteem behoudt. Dit stelt meerdere "organisaties" in staat om naast elkaar te bestaan, onafhankelijk, maar gedeelde huurder-vrije bronnen binnen de toepassing te delen. Net als bewoners die in een gebouw wonen, maakt elke organisatie gebruik van de toepassing zonder zich zorgen te maken over hun buren, aangezien de "organisatie" de benodigde scheiding biedt in de vorm van muren, gangen, deuren en sloten. Ze delen de algehele gebouwinfrastructuur, interieurontwerpsysteem en verschillende tastbare of ontastbare componenten.

Logto introduceert de "Organisatie"-functie in november#

Logto is momenteel bezig met de actieve ontwikkeling van de "Organisatie"-functie, die wordt gelanceerd in november 2023. Deze functie is specifiek ontworpen om te voldoen aan de huurderisoleringsvereisten die nodig zijn voor het bouwen van een SaaS-product, in lijn met industriestandaarden en beste praktijken.

In het volgende hoofdstuk gaan we dieper in op de "Organisatie"-functie en hoe Logto de implementatie van beste praktijken voor het bouwen van een multitenanttoepassing vergemakkelijkt.