Maar er zijn natuurlijk enkele bedrijven die bang zijn dat hun gegevens in gevaar komen, dus we evalueren andere oplossingen.
Dat is jammer, aangezien klanten soms de misvatting hebben dat alleen fysieke isolatie voldoende beveiliging kan bieden.
Er is een interessant MSDN-artikel, getiteld Multi-Tenant Data Architecture , die u misschien wilt controleren. Dit is hoe de auteurs de misvatting over de gedeelde benadering hebben aangepakt:
Een veel voorkomende misvatting is dat alleen fysieke isolatie een passend beveiligingsniveau kan bieden. Gegevens die zijn opgeslagen met behulp van een gedeelde benadering, kunnen ook sterke gegevensveiligheid bieden, maar vereisen het gebruik van meer geavanceerde ontwerppatronen.
Wat technische en zakelijke overwegingen betreft, maakt het artikel een korte analyse van waar een bepaalde benadering geschikter zou kunnen zijn dan een andere:
Het aantal, de aard en de behoeften van de huurders die u verwacht te dienen, zijn allemaal van invloed op uw beslissing over de data-architectuur. Sommige van de volgende vragen kunnen u vooroordelen in de richting van een meer geïsoleerde benadering, terwijl andere u misschien leiden tot een meer gedeelde benadering.
-
Op hoeveel potentiële huurders denkt u zich te richten? U kunt het toekomstige gebruik misschien nog lang niet met gezag inschatten, maar denk in ordes van grootte:bouwt u een applicatie voor honderden huurders? Duizenden? Tienduizenden? Meer? Hoe groter u verwacht dat uw huurdersbestand zal zijn, hoe groter de kans dat u een meer gedeelde aanpak wilt overwegen.
-
Hoeveel opslagruimte verwacht u dat de gegevens van de gemiddelde tenant in beslag nemen? Als u verwacht dat sommige of alle tenants zeer grote hoeveelheden gegevens zullen opslaan, is de benadering met afzonderlijke databases waarschijnlijk het beste. (In feite kunnen vereisten voor gegevensopslag u dwingen om toch een model met een afzonderlijke database te gebruiken. Als dat zo is, zal het veel gemakkelijker zijn om de toepassing vanaf het begin op die manier te ontwerpen dan later over te stappen op een benadering met een afzonderlijke database.)
-
Hoeveel gelijktijdige eindgebruikers verwacht u dat de gemiddelde huurder ondersteunt? Hoe groter het aantal, des te geschikter is een meer geïsoleerde benadering om aan de eisen van de eindgebruiker te voldoen.
-
Verwacht u per tenant services met toegevoegde waarde aan te bieden, zoals back-up- en herstelmogelijkheden per tenant? Dergelijke diensten zijn gemakkelijker aan te bieden door een meer geïsoleerde aanpak.
UPDATE: Verder om te updaten over het verwachte aantal huurders.
Dat verwachte aantal tenants (10k) zou de benadering met meerdere databases moeten uitsluiten, voor de meeste, zo niet alle scenario's. Ik denk niet dat je het idee zult hebben om 10.000 database-instanties te onderhouden en elke dag honderden nieuwe te moeten maken.
Alleen al op basis van die parameter lijkt het erop dat de benadering met een gedeelde database en één schema het meest geschikt is. Het feit dat u zo'n 50 MB per tenant opslaat en dat er geen add-ons per tenant zijn, maakt deze aanpak nog geschikter.
Het hierboven geciteerde MSDN-artikel vermeldt drie beveiligingspatronen die beveiligingsoverwegingen voor de benadering met gedeelde databases aanpakken:
Als u zeker bent van de gegevensveiligheidsmaatregelen van uw toepassing, kunt u uw klanten een Service Level Agreement aanbieden dat sterke garanties voor gegevensveiligheid biedt. In uw SLA zou u naast de garanties ook de maatregelen kunnen beschrijven die u zou nemen om ervoor te zorgen dat gegevens niet in gevaar komen.
UPDATE 2: Blijkbaar hebben de jongens van Microsoft een nieuw artikel over dit onderwerp verplaatst / gemaakt, de originele link is verdwenen en dit is de nieuwe:Multi-tenant SaaS-databasehuurpatronen (kudos voor Shai Kerer)