Vi tilbyr _multi-tenant tjenester_, noe som betyr at vi leverer skytjenester til mange ulike kunder. Derfor er det avgjørende for oss å holde data adskilt mellom kunder og forhindre at informasjon lekker fra en kunde til en annen.
Vi tilbyr multitenant- tjeneste, noe som betyr at vi leverer skytjenester til mange ulike kunder. Derfor er det avgjørende for oss å holde data adskilt mellom kunder og forhindre at informasjon lekker fra en kunde til en annen.
Våre tjenester leveres gjennom Microsoft Azure skyplattform, noe som betyr at vi deler den underliggende maskinvaren med andre Microsoft-kunder. Derfor er våre segregeringsstrategier basert på logisk segregering, snarere enn fysisk.
Datasegregering handler om å holde kundedata adskilt når de lagres i en database (lagring), når de behandles (databehandling) og når de overføres (nettverk). I all hovedsak er fokuset på lagringssegregering for å forhindre at kunder får tilgang til andre kunders data.
Vi bruker forskjellige strategier for datasegregering basert på konteksten og kravene til applikasjonen det gjelder. Felles for alle strategier er at vi bruker tilgangskontrollmekanismer som en ekstra verifikasjon av riktig segregering. Vi kan se dette som en to-trinns løsning:
Denne "forsvar i dybden"-tilnærmingen sikrer at dersom en bruker klarer å lure ressursidentifikasjonslogikken og forsøker å forespørre en annen kundes data, vil brukerens mangel på tilgangsrettigheter forhindre at forespørselen lykkes.
Nedenfor skisserer vi de forskjellige strategiene vi bruker for ressursidentifikasjonslogikk, inkludert hvor logikken er plassert og hvordan den fungerer.
Denne løsningen omfatter separate instanser for alt av lagring, databehandling og internt nettverk, hvor vi oppretter hele miljøer for hver kunde. Den eneste delen som deles mellom kunder er gatewayen, der brukere får tilgang til applikasjonen. Denne tilnærmingen gjør at applikasjonen i seg selv ikke trenger å håndtere forskjellige kunder, siden det bare vil være en enkelt kunde innen hver instans. Det er infrastrukturen som håndterer kompleksiteten av multi-tenancy og sørger for korrekt ressursidentifikasjonslogikk, mens applikasjonen håndhever tilgangskontroll selv. Teknisk sett gir det også store muligheter for individuell tilpasning av løsninger, på bekostning av økt kompleksitet i forbindelse med drift.
Ulempen med tilnærmingen er at den vanligvis skalerer dårlig etter hvert som antallet kunder øker. Det vil etterhvert gi svært mange tilnærmet like miljøer som må administreres separat, noe som distribusjons- og oppgraderingsprosessen betydelig mer krevende ettersom hvert kundemiljø må oppgraderes individuelt.
Denne strategien brukes i situasjoner der antallet kunder er lavt og relativt statisk, og i tilfeller der applikasjonen ikke støtter bruk av delte instanser.
Denne typen løsning omfatter delte ressursene for databehandling, nettverk, ustrukturert lagring og cache-lagring, mens ulike strategier for å sikre at lagring av data holdes separat. Det viktigste kjennetegnet ved denne tilnærmingen er at den plasserer hele segregeringslogikken innenfor applikasjonen selv, snarere enn i infrastrukturen. Det betyr at applikasjonen selv er ansvarlig for både å identifisere ressurser tilhørende en kunde og å håndheve tilgangskontroll for disse ressursene.
Det er imidlertid ulike måter å skille strukturerte data i databaser som tar hensyn til forskjellige scenarier. Nedenfor beskriver vi de forskjellige måtene dette gjøres på i våre applikasjoner:
Valget mellom alternativene A, B og C avhenger hovedsakelig av nivået av interaksjon og samarbeid mellom forskjellige kunder (eng: tenants). Fordelen med alle disse tilnærmingene er en mye mer oversiktlig vedlikehold av nettverk og applikasjoner, som tillater samtidige applikasjonsoppgraderinger for alle kunder. Det sikrer også at ingen endringer i infrastrukturen er nødvendige når nye kunder legges til eller fjernes. Mye av det tunge arbeidet gjøres på forhånd, slik at når riktig håndhevelse av applikasjons- og kundekontekst er på plass, legger ikke nye kunder til kompleksitet.
