Köp en bevisad kontrollgräns
En autentiseringsplattform kan annonsera roller, granskningsloggar och isolering av hyresgäster, men dessa etiketter fastställer inte hur kontrollerna beter sig i köparens avsedda arbetsflöden. En upphandlingsbedömning bör fråga vem som kan läsa, exportera, ändra och administrera vilken kunds data, hur livscykelförändringar påverkar åtkomsten och vilka bevis som registrerar dessa åtgärder. En framgångsrik demonstration av en administratör är inte ett negativt test av obehörig åtkomst.
Azures identitetsvägledning för multitenant särskiljer autentisering, auktorisation och kommersiella rättigheter. Använd dessa distinktioner för att strukturera köparens frågor istället för att anta att en inloggningsroll täcker varje resurs och åtgärd. Den här artikeln är ett kravramverk, inte ett påstående om att EmailAuth eller en annan namngiven plattform implementerar de föreslagna kontrollerna. Ingen hyresgäst fick åtkomst, tillstånd ändrades eller produkt köptes.
Definiera köparens åtkomstmatris först
Lista förväntade användar- och tjänsteroller, hyresgästrelationer och resurser innan du granskar en leverantörs rollnamn. Inkludera domänkonfiguration, autentiseringsrapporter, rådata, exporter, integrationer, användaradministration och kommersiella inställningar där det är relevant. Ange för varje kombination om läsa, skapa, ändra, ta bort eller exportera ska tillåtas. Köparens avsedda gräns är den referens mot vilken produktbeteendet kan bedömas.
Anta inte att "skrivskyddad" utesluter export eller att "hyresgästadministratör" är begränsad till en hyresgäst utan bevis. Team med delad service kan legitimt behöva flera kunder, medan enskilda kundanvändare endast bör se deras godkända omfattning. Anteckna dessa undantag uttryckligen. En bred roll som accepteras för en rättegång bör inte tyst bli utformningen av produktionsåtkomst. Kräv att leverantören kartlägger faktiska roller till köparens matris och identifierar distinktioner som inte stöds.
Verifiera klientbindningen utanför gränssnittet
En hyresgäst väljare eller ett dolt navigeringsobjekt är inte tillräckligt bevis på isolering. Den autentiserade identiteten måste vara auktoriserad för den begärda resursen vid serversidans gräns. Kraven bör omfatta direktläsningar, sökningar, exporter, skrivningar och bakgrundsjobb, inklusive referenser till resurser som ägs av en annan hyresgäst. Använd syntetiska armaturer med synligt olika data så att ett oavsiktligt resultat av flera hyresgäster kan upptäckas.
Azures vägledning varnar för att federationsfelkonfiguration kan ge åtkomst till oavsiktliga hyresgäster. Granskningen bör därför omfatta hur identiteter förknippas med hyresgäster, vem som kan ändra den föreningen och hur en användare som tillhör flera hyresgäster väljer omfattning. Dra inte slutledning om äganderätt från enbart ett e-postsuffix eller anta att en kundtillhandahållen hyresgästidentifierare godkänner dess användning. Den faktiska leverantören måste förklara och visa sin modell som stöds.
Fråga vad revisionsloggen faktiskt registrerar
Microsoft Entras revisionsloggdokumentation beskriver aktivitetsposter för förändringar i den identitetsmiljön. Det är ett användbart exempel på en officiell revisionsloggmodell, inte bevis på att en annan plattform registrerar samma händelser. En köpare bör begära den exakta produktkatalogen, fältdefinitioner, åtkomstkontroller, lagringsbeteende och exportalternativ som är relevanta för deras egna krav.
Fråga om register identifierar aktören, målet, handlingen, tiden, resultatet och hyresgästens sammanhang tillräckligt för att undersöka en förändring. Skilj användaraktivitet från aktivitet med tjänstidentitet och framgångsrika åtgärder från nekade försök. Anta inte att varje misslyckat auktoriseringsförsök loggas bara för att administrativa ändringar dyker upp. På samma sätt kan en logg som visar att en begäran skickades inte visa om den resulterande ändringen slutfördes. Kräv faktiska exempel med känsliga uppgifter borttagna och angivna begränsningar.
Granska loggåtkomst och integritet som kontroller
En revisionslogg kan i sig innehålla känslig kund- och identitetsinformation. Definiera vem som får se det, sök bland hyresgäster, exportera det och konfigurera dets kvarhållning. En administratör som kan ändra en inställning och radera de enda bevisen presenterar en annan ansvarsmodell än en med oberoende lagrade register. Fråga leverantören hur dessa kontroller fungerar, men gör inte anspråk på oföränderlighet eller manipuleringsmotstånd utan aktuella bevis.
Retention bör specificeras av produktens faktiska villkor och köparens skyldigheter, inte en påhittad universell period. Förtydliga vilka händelser som är tillgängliga i gränssnittet, API och exporterade arkiv och om dessa vyer har samma täckning. Granska tidszonshantering och identifierare så att poster kan korreleras utan att förlita sig på namn som kan ändras. Inga revisionsprotokoll hämtades för detta manuskript.
Testa livscykelförändringar och serviceåtkomst
En rollreduktion, inaktivering av användare och återkallande av autentiseringsuppgifter är separata händelser. RFC 7643 beskriver det aktiva attributet SCIM samtidigt som det lämnar dess definitiva betydelse till tjänsteleverantören. Det illustrerar varför en köpare inte kan anta att en provisioneringsuppdatering återkallar alla befintliga sessioner eller integreringsuppgifter. Kräv en aktuell förklaring av produktens session och beteende för icke-interaktiv åtkomst.
Acceptansplanen bör inkludera en användare vars roll är reducerad medan en session existerar, en inaktiverad identitet, en integration med begränsad omfattning och en auktoriserad administratör. Verifiera det avsedda åtkomstresultatet i varje fall, inklusive export och direkt resursoperationer. Dessa är föreslagna kontroller för en auktoriserad isolerad miljö, inte tillstånd att testa en leverantörs produktionstjänst eller en annan kunds hyresgäst. Ingen sådan åtgärd utfördes här.
Ett kalkylblad för köpareacceptans
Skapa ett kalkylblad med krav, affärsorsak, leverantörsanspråk, stödd konfiguration, fixturidentitet, hyresgäst, åtgärd, förväntat resultat, faktiska bevis och olösta begränsningar. Håll bevis för tillåtna handlingar åtskilda från bevis för nekade handlingar. Inkludera produktversion, testdatum och miljö så att resultatet förblir tolkningsbart efter en release. Om en funktion är planerad snarare än implementerad, registrera den statusen utan att behandla den som aktuell täckning.
För granskningsloggar, lägg till den förväntade händelsen och den observerade postreferensen för varje åtgärd där loggning krävs. Ett test som korrekt nekar åtkomst men som inte ger några förväntade revisionsbevis har ett annat resultat än ett som uppfyller båda kriterierna. Registrera vem som accepterar någon begränsning och om en kompenserande kontroll är godkänd. Förvandla inte poängen för en upphandlingschecklista till en garanti för framtida säkerhet.
Fiktiv diagnos: en tittare som kan exportera
En fiktiv köpare ser en leverantörsdemonstration där en tittare inte kan redigera domäninställningar. Köparen markerar initialt skrivskyddsrollen som tillfredsställande. Den avsedda matrisen förbjuder dock även massexport av rå kunddata. Demonstrationen testade aldrig export, direkt resursbegäran eller tillgång till en annan hyresgästs rapport. Den observerade begränsningen omfattar endast en åtgärd.
Det föreslagna svaret är att be om auktoriserade fixturbaserade bevis över de saknade operationerna och granska de resulterande revisionsprotokollen. Om produkten inte kan separera visning från export måste köparen bestämma om den begränsningen är acceptabel istället för att byta namn på rollen och anta att risken försvann. Detta är en fiktiv upphandlingsövning, inte ett fynd om EmailAuth eller någon namngiven leverantör.
Håll inköpsslutsatsen begränsad
En användbar slutsats identifierar krav som uppfylls av bevis, krav som inte är uppfyllda, begränsningar accepterade av en ägare och tester som fortfarande är öppna. Den skiljer konfigurationsval från inneboende produktbeteende och lovar inte perfekt isolering från en ändlig testuppsättning. Beslutet kan informeras utan att hävda att varje framtida version eller konfiguration omfattas.
Katalogen kräver en åtkomstmatris och negativa tester för läsning, export, skrivning och livscykelförändringar mellan klienter. Dessa ursprungliga tester förblir öppna. Mänsklig specialistgranskning, källans tillämplighet, produktionsvägar, tillgänglighet och ägarefrisläppande förblir också öppna. Detta utkast tillhandahåller bedömningsmetoden, inte en köprekommendation baserad på utförda bevis, och inga kommersiella åtaganden eller tillträdesbidrag har gjorts.