En MSP-tjeneste kan præsentere mange kunder i én konsol, mens de stadig har brug for streng adskillelse af deres data og autoritet. Lejerisolation betyder, at enhver anmodning og afledte artefakter forbliver inden for det lejeromfang, som den nuværende rektor har adgang til. En kunde vælger i en browser er ikke en sikkerhedsgrænse.
Kortlæg grænserne
Liste rapportposter, domænebeholdning, konfigurationsforslag, eksporter, revisionsbegivenheder og planlagte job. Identificer, hvordan hvert objekt bærer lejerkontekst, og hvor adgangen håndhæves. OWASPs vejledning til flere lejere behandler lejerkontekst som et sikkerhedsproblem på tværs af applikations- og datalag; dens autorisationsvejledning anbefaler standardafvisning og kontrol af hver anmodning.
Udled lejeromfanget fra betroet autentificeret kontekst og godkendt medlemskab. Behandl et lejer-id, der er angivet i en URL eller nyttelast, som upålidelig input til validering, ikke som tilstrækkelig autoritet. Når et baggrundsjob kører, skal du bevare den initierende lejer og kontrollere de nødvendige tilladelser til handlingen igen. MSP-analytikere på tværs af kunder har brug for eksplicitte tilskud til flere lejere, ikke en bypass udledt af deres jobtitel.
Test ressourcer og drift uafhængigt
Brug to fiktive kunder med forskellige rapporter og domæneobjekter. Forsøg en tilladt læsning, og skift derefter kun ressource-id'et. Gentag for eksportdownload, foreslået DNS -skrivning og brugerstyringsændring. Test direkte API-anmodninger, fordi en usynlig knap ikke forhindrer en udformet anmodning. Bekræft afvisning afslører ikke rapportindhold eller objektdetaljer, der er unødvendige for svaret.
Test cachelagrede resultater, søgeindekser og genererede eksporter samt databaseforespørgsler. En forespørgsel med korrekt omfang kan stadig lække data gennem en cache-nøgle, der udelader lejeridentitet. Eksportlager og downloadgodkendelse kræver deres egne negative tests. Medtag rolleændringer, suspenderede konti og fjernet medlemskab; en forældet session må ikke bevare tilbagetrukne privilegier på ubestemt tid.
Følg en rapport til dens eksporterede artefakt
Antag, at lejer A's rapport API korrekt nægter lejer B, men en tidligere genereret eksport kan downloades ved kun at ændre dens objekt-id. API-testen bestod inden for sit omfang, men eksportisolering mislykkedes. Bevar anmodningen og artefaktbeviset uden at indsamle unødvendige kundedata, begræns den berørte adgang gennem den autoriserede hændelsesproces og undersøg eksponeringen, før piloten udvides.
I et separat tilfælde forlader en analytiker kontoen efter at have planlagt en eksport. Jobforbrugeren skal genetablere betroet lejerkontekst og kontrollere gældende autorisation, når den udfører arbejdet; en historisk kø-aflevering er ikke et varigt tilskud. Disse er hypotetiske fejlscenarier, ikke resultater fra et faktisk produkt. Test både en gyldig scoped download og forbudte anmodninger ved den rigtige API, job- og lagergrænser, bibeholdelse af identitet, lejer, drift, objekt og observeret resultat uden hemmeligheder.
Definer genopretning og beviser
Sørg for, at isolationsfejl kan skelnes fra almindelige manglende ressourcefejl i begrænsede driftslogfiler, mens du undgår unødvendige afsløringer til opkaldere. Registrer hændelsens omfang, berørte artefakter, indeslutning og re-testresultater. Slet ikke beviser for at gøre testen ren.
Accept kræver vellykkede tilladte stier og mislykkede forbudte stier på tværs af alle relevante operationer. En enkelt bestået matrix beviser ikke, at al applikationskode er isoleret. Kør test igen efter ændringer af tilladelsesmodel, lagring, cache, eksport eller jobsystem. Vurder delt infrastruktur og privilegeret supportadgang eksplicit med tidsbegrænsede bevillinger og revisionsgennemgang, hvor det er nødvendigt.