Wat is multi-tenancy?
Software multi-tenancy is een software-architectuur waarbij een enkele instantie van software op een server draait en meerdere huurders bedient. Systemen die op deze manier zijn ontworpen, zijn “gedeeld” (in plaats van “toegewijd” of “geïsoleerd”).
Een huurder is een groep gebruikers die gemeenschappelijke toegang delen met specifieke privileges tot de software-instantie.
De multi-tenant architectuur wordt vaak geprefereerd wanneer serviceproviders gestandaardiseerde diensten aanbieden aan meerdere klanten. Deze diensten hebben meestal minimale maatwerkopties en alle klanten delen dezelfde applicatie-instantie. Wanneer de applicatie wordt bijgewerkt, geldt dit voor alle klanten tegelijk.
Een voorbeeld hiervan is een CRM (Customer Relationship Management) systeem dat vaak gebruikmaakt van multi-tenant architectuur om dezelfde dienst aan alle klanten te leveren.
Een belangrijk principe van multi-tenancy is “delen.” Dit betekent niet dat elk onderdeel van de oplossing wordt gedeeld; het betekent dat ten minste sommige componenten worden hergebruikt voor meerdere huurders. Het begrijpen van dit bredere concept kan je helpen beter in te spelen op de behoeften van je klanten.
Wat zijn de gebruikssituaties voor multi-tenant producten?
Multi-tenant apps worden vaak gebruikt in software-as-a-service (SaaS) producten zoals productiviteitstools, samenwerkingssoftware, enzovoort. In deze opzet vertegenwoordigt elke “huurder” meestal een zakelijke klant, met meerdere gebruikers (typisch werknemers). Afhankelijk van het product kan het worden aangeduid als een huurder, werkruimte of project. Een enkel bedrijf kan ook meerdere huurders hebben die verschillende divisies of organisaties vertegenwoordigen.
In meer complexe gevallen, zoals B2B-applicaties buiten SaaS, bieden multi-tenant apps een gedeeld platform voor verschillende teams, zakelijke klanten en partnerbedrijven om toegang te krijgen tot je diensten.
Waarom zou je multi-tenancy in een SaaS-product moeten gebruiken?
Schalen met multi-tenancy
Voor ondernemingen is multi-tenancy de sleutel tot het effectief voldoen aan hun eisen voor beschikbaarheid, middelenbeheer, kostenbeheer en gegevensbeveiliging. Op technisch niveau vereenvoudigt het aannemen van een multi-tenant aanpak je ontwikkelprocessen, minimaliseert het technische uitdagingen en bevordert het naadloze uitbreiding.
Een uniforme ervaring creëren
Wanneer we kijken naar de oorsprong van SaaS-producten, is het vergelijkbaar met een gebouw met verschillende appartementen. Alle huurders delen gemeenschappelijke voorzieningen zoals water, elektriciteit en gas, maar ze behouden onafhankelijke controle over het beheer van hun eigen ruimte en middelen. Deze aanpak vereenvoudigt vastgoedbeheer.
Zorgen voor beveiliging door huurdersisolatie
In een multi-tenancy architectuur wordt de term “huurder” geïntroduceerd om grenzen te creëren die de middelen en gegevens van verschillende huurders binnen een gedeelde instantie scheiden en beveiligen. Dit garandeert dat de gegevens en activiteiten van elke huurder apart en veilig blijven, zelfs als ze dezelfde onderliggende middelen gebruiken.
Hoe bereik je huurdersisolatie in multi-tenancy architectuur?
Bij het bespreken van multi-tenant applicaties, is het altijd noodzakelijk om huurdersisolatie te bereiken. Dit betekent het gescheiden en veilig houden van de gegevens en middelen van verschillende huurders binnen een gedeeld systeem (bijvoorbeeld een cloudinfrastructuur of een multi-tenant applicatie). Dit voorkomt ongeoorloofde pogingen om toegang te krijgen tot de middelen van een andere huurder.
Hoewel de uitleg abstract kan lijken, zullen we voorbeelden en belangrijke details gebruiken om de isolatiemindset en de beste praktijk om huurdersisolatie te bereiken verder uit te leggen.
Huurdersisolatie gaat niet in tegen het “gedeelde” gedachtegoed van multi-tenancy
Dat komt omdat huurdersisolatie niet noodzakelijkerwijs een construct op het niveau van infrastructuurmiddelen is. In de wereld van multi-tenancy en isolatie zien sommigen isolatie als een strikte scheiding tussen echte infrastructuurmiddelen. Dit leidt meestal tot een model waarbij elke huurder afzonderlijke databases, computerinstanties, accounts of privéclouds heeft. In gedeelde middelen scenario’s, zoals multi-tenant apps, kan de manier om isolatie te bereiken een logisch construct zijn.
In het ontwerp van de architectuur kunnen verschillende graden van middelenisolatie tussen huurders worden bereikt:
Over het algemeen geldt: hoe meer middelen gedeeld worden tussen huurders, des te lager de kosten van systeemiteratie en -onderhoud. Omgekeerd, hoe minder gedeelde middelen, hoe hoger de kosten.
Huurdersisolatie richt zich uitsluitend op het gebruik van de “huurder” context om toegang tot middelen te beperken. Het evalueert de context van de huidige huurder en gebruikt die context om te bepalen welke middelen toegankelijk zijn voor die huurder.
Authenticatie en autorisatie zijn niet gelijk aan “isolatie”
Het gebruik van authenticatie en autorisatie om 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 stellen vaak de vraag, kan ik algemene autorisatieoplossingen en op rollen gebaseerde toegang beheren gebruiken om huurdersisolatie te bereiken?
Je kunt een multi-tenant app bouwen, maar je kunt niet zeggen dat je huurdersisolatie strategieën hebt bereikt en toegepast als beste praktijk. We raden het over het algemeen niet aan, omdat huurdersisolatie gescheiden is van authenticatie en autorisatie.
Ter illustratie: overweeg een situatie waarin je authenticatie en autorisatie voor je SaaS-systeem hebt ingesteld. Wanneer gebruikers inloggen, ontvangen ze een token met informatie over hun rol, die bepaalt wat ze in de applicatie kunnen doen. Deze aanpak verhoogt de beveiliging, maar garandeert geen isolatie.
Gebruik “organisatie” als context om de SaaS-producthuurder te vertegenwoordigen, voor het bereiken van huurdersisolatie
Door uitsluitend te vertrouwen op authenticatie en autorisatie voorkom je niet dat een gebruiker met de juiste rol toegang krijgt tot de middelen van een andere huurder. We moeten daarom een “huurder” context integreren, zoals een huurder-ID, om de toegang tot middelen te beperken.
Dit is waar huurdersisolatie in het spel komt. Het gebruikt huurder-specifieke identificaties om grenzen te creëren, net zoals muren, deuren en sloten, wat zorgt voor een duidelijke scheiding tussen huurders.
Hoe worden identiteiten beheerd in multi-tenant apps?
We hebben huurdersisolatie besproken, maar hoe zit het met identiteiten? Hoe beslis je of je identiteiten “geïsoleerd” moeten zijn of niet?
Er is vaak verwarring rond het concept “Identiteitsisolatie.” Het kan verwijzen naar situaties waar één echte gebruiker twee identiteiten heeft in het algemene begrip van mensen.
- Beide identiteiten kunnen binnen een enkel identiteitsysteem bestaan. Bijvoorbeeld, Sarah kan een persoonlijk e-mailadres hebben geregistreerd naast een zakelijk e-mailadres dat is verbonden via single sign-on (SSO).
- Gebruikers onderhouden twee verschillende identiteiten binnen afzonderlijke identiteitsystemen, wat volledig gescheiden producten vertegenwoordigt. Deze producten zijn volledig los van elkaar.
Soms worden deze scenario’s “identiteitsisolatie” genoemd, maar die term helpt misschien niet bij het nemen van beslissingen.
In plaats van te vragen of je “identiteitsisolatie” nodig hebt, denk na over of delen van je bedrijf of product aparte identiteitsystemen vereisen. Dit zal je systeemontwerp begeleiden. Voor multi-tenant apps zijn identiteiten in de meeste gevallen gedeeld, terwijl de middelen van elke huurder gescheiden worden gehouden.
In multi-tenant apps worden identiteiten gedeeld over huurders, in tegenstelling tot huurder-specifieke middelen en gegevens. Het is als een gebouwbeheerder zijn — je zou niet twee afzonderlijke lijsten van namen van huurders willen onderhouden.
Bij het nastreven van huurdersisolatie komt de term “organisatie” vaak naar voren, aangezien het een beste praktijk is voor het bouwen van multi-tenant apps.
Door “organisatie” te gebruiken in veel CIAM (Customer Identity Management) of Auth-diensten, kun je huurdersisolatie bereiken in je multi-tenant app terwijl je toch een verenigd identiteitsysteem behoudt.
Hoe kies je de juiste autorisatiemodellen voor betere toegang beheersing?
Bij het kiezen van het juiste autorisatiemodel, overweeg deze vragen:
- Ontwikkel je een B2C, B2B, of een combinatie van beide soorten producten?
- Heeft je app een multi-tenant architectuur?
- Is er behoefte aan een bepaald isolatieniveau in je app, zoals bepaald door de bedrijfseenheid?
- Welke permissies en rollen moeten worden gedefinieerd binnen de context van de organisatie, en welke niet?