Kjøp en bevist kontrollgrense
En autentiseringsplattform kan annonsere roller, revisjonslogger og leietakerisolasjon, men disse etikettene fastslår ikke hvordan kontrollene oppfører seg i kjøperens tiltenkte arbeidsflyter. En anskaffelsesvurdering bør spørre hvem som kan lese, eksportere, endre og administrere hvilke kundedata, hvordan endringer i livssyklusen påvirker tilgangen og hvilke bevis som registrerer disse handlingene. En vellykket demonstrasjon av en administrator er ikke en negativ test av uautorisert tilgang.
Azures multitenant-identitetsveiledning skiller autentisering, autorisasjon og kommersielle rettigheter. Bruk disse distinksjonene til å strukturere kjøperspørsmål i stedet for å anta at en påloggingsrolle dekker hver ressurs og handling. Denne artikkelen er et kravrammeverk, ikke en påstand om at EmailAuth eller en annen navngitt plattform implementerer de foreslåtte kontrollene. Ingen leietaker ble åpnet, tillatelse endret eller produkt kjøpt.
Definer kjøperens tilgangsmatrise først
List opp forventede bruker- og tjenesteroller, leietakerforhold og ressurser før du gjennomgår en leverandørs rollenavn. Inkluder domenekonfigurasjon, autentiseringsrapporter, rådata, eksporter, integrasjoner, brukeradministrasjon og kommersielle innstillinger der det er relevant. Angi for hver kombinasjon om lesing, opprettelse, endring, sletting eller eksport skal tillates. Kjøperens tiltenkte grense er referansen som produktadferd kan vurderes mot.
Ikke anta at «skrivebeskyttet» utelukker eksport eller at «leietakeradministrator» er begrenset til én leietaker uten bevis. Delt tjenesteteam kan legitimt trenge flere kunder, mens individuelle kundebrukere bare skal se deres godkjente omfang. Noter disse unntakene eksplisitt. En bred rolle som aksepteres for en prøveperiode, bør ikke i det stille bli produksjonstilgangsdesignet. Krev at leverandøren kartlegger faktiske roller til kjøperens matrise og identifiserer ustøttede distinksjoner.
Bekreft leietakerbinding utenfor grensesnittet
En leietaker velger eller et skjult navigasjonselement er ikke tilstrekkelig bevis på isolasjon. Den autentiserte identiteten må være autorisert for den forespurte ressursen på serversidegrensen. Kravene bør dekke direkte lesing, søk, eksport, skriving og bakgrunnsjobber, inkludert referanser til ressurser som eies av en annen leietaker. Bruk syntetiske armaturer med synlig forskjellige data slik at et tilfeldig resultat på tvers av leietakere kan oppdages.
Azures veiledning advarer om at feilkonfigurasjon av føderasjon kan gi tilgang til utilsiktede leietakere. Gjennomgangen bør derfor inkludere hvordan identiteter er knyttet til leietakere, hvem som kan endre den tilknytningen og hvordan en bruker som tilhører flere leietakere velger omfang. Ikke utlede eierskap fra et e-postsuffiks alene eller anta at en kundelevert leietaker-identifikator autoriserer bruken. Den faktiske leverandøren må forklare og demonstrere sin støttede modell.
Spør hva revisjonsloggen faktisk registrerer
Microsoft Entras revisjonsloggdokumentasjon beskriver aktivitetsposter for endringer i det identitetsmiljøet. Det er et nyttig eksempel på en offisiell revisjonsloggmodell, ikke bevis på at en annen plattform registrerer de samme hendelsene. En kjøper bør be om den eksakte produkthendelseskatalogen, feltdefinisjoner, tilgangskontroller, oppbevaringsatferd og eksportalternativer som er relevante for deres egne krav.
Spør om registreringer identifiserer aktøren, målet, handlingen, tiden, resultatet og leietakerkonteksten tilstrekkelig til å undersøke en endring. Skille brukeraktivitet fra tjenesteidentitetsaktivitet og vellykkede handlinger fra avviste forsøk. Ikke anta at hvert mislykkede autorisasjonsforsøk blir logget bare fordi administrative endringer vises. På samme måte kan det hende at en logg som viser at en forespørsel ble sendt ikke viser om den resulterende endringen ble fullført. Krev faktiske eksempler med sensitive data redigert og begrensninger angitt.
Gjennomgå loggtilgang og integritet som kontroller
En revisjonslogg kan i seg selv inneholde sensitiv kunde- og identitetsinformasjon. Definer hvem som kan se den, søk på tvers av leietakere, eksporter den og konfigurer oppbevaringen. En administrator som kan endre en innstilling og slette de eneste bevisene, presenterer en annen ansvarlighetsmodell enn en med uavhengig beholdte poster. Spør leverandøren hvordan disse kontrollene fungerer, men ikke hevder uforanderlighet eller manipulasjonsmotstand uten nåværende bevis.
Oppbevaring bør spesifiseres av produktets faktiske støttede vilkår og kjøperens forpliktelser, ikke en oppfunnet universell periode. Avklar hvilke hendelser som er tilgjengelige i grensesnittet, API og eksportert arkiv og om disse visningene har samme dekning. Gjennomgå tidssonehåndtering og identifikatorer slik at poster kan korreleres uten å stole på navn som kan endres. Ingen revisjonsprotokoller ble hentet for dette manuskriptet.
Test livssyklusendringer og tjenestetilgang
En rollereduksjon, deaktivering av bruker og tilbakekalling av legitimasjon er separate hendelser. RFC 7643 beskriver det aktive SCIM-attributtet mens det overlater den definitive betydningen til tjenesteleverandøren. Det illustrerer hvorfor en kjøper ikke kan anta at en klargjøringsoppdatering tilbakekaller alle eksisterende økter eller integrasjonslegitimasjon. Krev en aktuell forklaring av produktets økt og atferd med ikke-interaktiv tilgang.
Akseptplanen bør inkludere en bruker hvis rolle er redusert mens en økt eksisterer, en deaktivert identitet, en integrasjon med begrenset omfang og en autorisert administrator. Bekreft det tiltenkte tilgangsresultatet i hvert enkelt tilfelle, inkludert eksport og direkte ressursoperasjoner. Dette er foreslåtte kontroller for et autorisert isolert miljø, ikke tillatelse til å teste en leverandørs produksjonstjeneste eller en annen kundes leietaker. Ingen slik handling ble utført her.
Et arbeidsark for kjøperaksept
Lag et regneark med krav, forretningsgrunn, leverandørkrav, støttet konfigurasjon, armaturidentitet, leietaker, handling, forventet resultat, faktisk bevis og uløst begrensning. Hold bevis for tillatte handlinger atskilt fra bevis for avviste handlinger. Inkluder produktversjon, testdato og miljø slik at resultatet forblir tolkbart etter en utgivelse. Hvis en funksjon er planlagt i stedet for implementert, registrerer du den statusen uten å behandle den som gjeldende dekning.
For revisjonslogger, legg til den forventede hendelsen og den observerte postreferansen for hver handling der logging er nødvendig. En test som korrekt nekter tilgang, men som ikke produserer forventet revisjonsbevis, har et annet utfall enn en som tilfredsstiller begge kriteriene. Registrer hvem som godtar enhver begrensning og om en kompenserende kontroll er godkjent. Ikke gjør en anskaffelsessjekklistescore til en garanti for fremtidig sikkerhet.
Fiktiv diagnose: en seer som kan eksportere
En fiktiv kjøper ser en leverandørdemonstrasjon der en seer ikke kan redigere domeneinnstillinger. Kjøper markerer i utgangspunktet skrivebeskyttet rolle som tilfredsstillende. Den tiltenkte matrisen forbyr imidlertid også masseeksport av rå kundedata. Demonstrasjonen testet aldri eksport, direkte ressursforespørsler eller tilgang til en annen leietakers rapport. Den observerte begrensningen dekker kun én handling.
Det foreslåtte svaret er å be om autorisert inventarbasert bevis på tvers av de manglende operasjonene og gjennomgå de resulterende revisjonsprotokollene. Hvis produktet ikke kan skille visning fra eksport, må kjøperen avgjøre om den begrensningen er akseptabel i stedet for å gi nytt navn til rollen og anta at risikoen forsvant. Dette er en fiktiv innkjøpsøvelse, ikke et funn om EmailAuth eller noen navngitt leverandør.
Hold kjøpskonklusjonen begrenset
En nyttig konklusjon identifiserer krav møtt av bevis, krav som ikke er oppfylt, begrensninger akseptert av en eier og tester som fortsatt er åpne. Den skiller konfigurasjonsvalg fra iboende produktadferd og lover ikke perfekt isolasjon fra et begrenset testsett. Beslutningen kan informeres uten å hevde at enhver fremtidig versjon eller konfigurasjon dekkes.
Katalogen krever en tilgangsmatrise og negative tester for lesing, eksport, skriving og livssyklusendringer på tvers av leietakere. De originale testene forblir åpne. Gjennomgang av menneskelig spesialist, kildeanvendbarhet, produksjonsruter, tilgjengelighet og eierfrigivelse forblir også åpne. Dette utkastet gir vurderingsmetoden, ikke en kjøpsanbefaling basert på utført bevis, og ingen kommersiell forpliktelse eller tilgangsbevilgning er gitt.