Koop een bewezen controlegrens
Een authenticatieplatform kan rollen, auditlogboeken en huurderisolatie adverteren, maar deze labels leggen niet vast hoe de controles zich gedragen in de beoogde workflows van de koper. Bij een aanbestedingsbeoordeling moet worden gevraagd wie welke klantgegevens kan lezen, exporteren, wijzigen en beheren, hoe veranderingen in de levenscyclus de toegang beïnvloeden en welk bewijsmateriaal deze acties registreert. Een succesvolle demonstratie door een beheerder is geen negatieve test voor ongeautoriseerde toegang.
De identiteitsrichtlijnen voor meerdere tenants van Azure maakt onderscheid tussen authenticatie, autorisatie en commerciële rechten. Gebruik dit onderscheid om de vragen van kopers te structureren, in plaats van ervan uit te gaan dat een inlogrol alle bronnen en acties omvat. Dit artikel is een raamwerk van eisen en niet een claim dat EmailAuth of een ander genoemd platform de voorgestelde controles implementeert. Er is geen toegang verkregen tot een tenant, er is geen toestemming gewijzigd of er is geen product aangeschaft.
Definieer eerst de toegangsmatrix van de koper
Maak een lijst van de verwachte gebruikers- en servicerollen, huurderrelaties en resources voordat u de rolnamen van een leverancier bekijkt. Inclusief domeinconfiguratie, authenticatierapporten, onbewerkte gegevens, exports, integraties, gebruikersbeheer en commerciële instellingen waar relevant. Geef per combinatie aan of lezen, aanmaken, wijzigen, verwijderen of exporteren mag. De beoogde grens van de koper is de referentie waartegen het productgedrag kan worden beoordeeld.
Ga er niet van uit dat “alleen-lezen” export uitsluit of dat “tenantbeheerder” zonder bewijs beperkt is tot één huurder. Gedeelde serviceteams kunnen terecht meerdere klanten nodig hebben, terwijl individuele klantgebruikers alleen hun goedgekeurde bereik mogen zien. Leg deze uitzonderingen expliciet vast. Een brede rol die voor een proef wordt geaccepteerd, mag niet stilletjes het ontwerp van de productietoegang worden. Vereisen dat de leverancier daadwerkelijke rollen in kaart brengt in de matrix van de inkoper en niet-ondersteunde verschillen identificeert.
Controleer de tenantbinding buiten de interface
Een huurder keuzeschakelaar of een verborgen navigatie-item is geen voldoende bewijs van isolatie. De geverifieerde identiteit moet worden geautoriseerd voor de aangevraagde bron op de grens aan de serverzijde. Vereisten moeten directe lees-, zoek-, export-, schrijf- en achtergrondtaken omvatten, inclusief verwijzingen naar bronnen die eigendom zijn van een andere tenant. Gebruik synthetische armaturen met zichtbaar verschillende gegevens, zodat een onbedoeld cross-tenant resultaat detecteerbaar is.
De richtlijnen van Azure waarschuwen dat een verkeerde configuratie van de federatie toegang kan verlenen aan onbedoelde tenants. De beoordeling moet daarom omvatten hoe identiteiten aan tenants worden gekoppeld, wie die koppeling kan wijzigen en hoe een gebruiker die tot meerdere tenants behoort, het bereik selecteert. Leid het eigendom niet alleen af op basis van een e-mailachtervoegsel en ga er ook niet van uit dat een door de klant verstrekte tenant-ID het gebruik ervan autoriseert. De daadwerkelijke leverancier moet het ondersteunde model uitleggen en demonstreren.
Vraag wat het auditlogboek feitelijk registreert
De auditlogdocumentatie van Microsoft Entra beschrijft activiteitsrecords voor wijzigingen in die identiteitsomgeving. Het is een nuttig voorbeeld van een officieel auditlogboekmodel en geen bewijs dat een ander platform dezelfde gebeurtenissen registreert. Een koper moet de exacte productgebeurteniscatalogus, velddefinities, toegangscontroles, retentiegedrag en exportopties opvragen die relevant zijn voor zijn eigen vereisten.
Vraag of records de actor, het doel, de actie, het tijdstip, het resultaat en de huurdercontext voldoende identificeren om een verandering te onderzoeken. Onderscheid gebruikersactiviteit van service-identiteitsactiviteit en succesvolle acties van geweigerde pogingen. Ga er niet vanuit dat elke mislukte autorisatiepoging alleen maar wordt geregistreerd omdat er administratieve wijzigingen optreden. Op dezelfde manier kan uit een logboek waaruit blijkt dat een verzoek is ingediend, niet blijken of de resulterende wijziging is voltooid. Vereist concrete voorbeelden waarbij gevoelige gegevens zijn geredigeerd en de beperkingen zijn vermeld.
Controleer de logtoegang en -integriteit als controlemechanismen
Een auditlogboek kan zelf gevoelige klant- en identiteitsinformatie bevatten. Bepaal wie het mag bekijken, zoek in verschillende tenants, exporteer het en configureer de retentie ervan. Een beheerder die een instelling kan wijzigen en het enige bewijsmateriaal kan wissen, hanteert een ander verantwoordingsmodel dan een model met onafhankelijk bewaarde gegevens. Vraag de leverancier hoe deze controles werken, maar claim geen onveranderlijkheid of manipulatiebestendigheid zonder actueel bewijs.
De retentie moet worden gespecificeerd door de feitelijk ondersteunde voorwaarden van het product en de verplichtingen van de koper, en niet door een verzonnen universele periode. Maak duidelijk welke gebeurtenissen beschikbaar zijn in de interface, de API en het geëxporteerde archief en of deze weergaven dezelfde dekking hebben. Controleer de afhandeling en identificatie van tijdzones, zodat records kunnen worden gecorreleerd zonder te vertrouwen op namen die kunnen veranderen. Voor dit manuscript zijn geen auditgegevens opgehaald.
Test levenscycluswijzigingen en servicetoegang
Een rolreductie, het uitschakelen van een gebruiker en het intrekken van de inloggegevens zijn afzonderlijke gebeurtenissen. RFC 7643 beschrijft het actieve SCIM-attribuut en laat de definitieve betekenis ervan over aan de serviceprovider. Dat illustreert waarom een koper er niet van kan uitgaan dat een inrichtingsupdate alle bestaande sessies of integratiereferenties intrekt. Vereist een actuele uitleg van de sessie en het gedrag van niet-interactieve toegang van het product.
Het acceptatieplan moet een gebruiker bevatten wiens rol wordt verminderd zolang er een sessie bestaat, een uitgeschakelde identiteit, een integratie met beperkte reikwijdte en een geautoriseerde beheerder. Controleer in elk geval het beoogde toegangsresultaat, inclusief exporten en directe resourcebewerkingen. Dit zijn voorgestelde controles voor een geautoriseerde geïsoleerde omgeving, geen toestemming om de productiedienst van een leverancier of de huurder van een andere klant te testen. Een dergelijke actie is hier niet uitgevoerd.
Een werkblad voor koperacceptatie
Maak een werkblad met de vereiste, zakelijke reden, claim van de leverancier, ondersteunde configuratie, identiteit van het armatuur, huurder, actie, verwacht resultaat, feitelijk bewijs en onopgeloste beperking. Houd bewijsmateriaal van toegestane handelingen gescheiden van bewijsmateriaal van geweigerde handelingen. Vermeld de productversie, testdatum en omgeving, zodat het resultaat ook na release interpreteerbaar blijft. Als een functie gepland is in plaats van geïmplementeerd, registreer dan die status zonder deze als huidige dekking te beschouwen.
Voeg voor auditlogboeken de verwachte gebeurtenis en de waargenomen recordreferentie toe voor elke actie waarvoor logboekregistratie vereist is. Een test die terecht de toegang ontzegt maar geen verwachte controle-informatie oplevert, heeft een andere uitkomst dan een test die aan beide criteria voldoet. Leg vast wie eventuele beperkingen accepteert en of een compenserende controle wordt goedgekeurd. Maak van een inkoopchecklistscore geen garantie voor toekomstige veiligheid.
Fictieve diagnose: een kijker die kan exporteren
Een fictieve koper ziet een leveranciersdemonstratie waarin een kijker de domeininstellingen niet kan bewerken. De koper bestempelt de alleen-lezen-rol in eerste instantie als bevredigend. De beoogde matrix verbiedt echter ook bulkexport van ruwe klantgegevens. Bij de demonstratie zijn exporten, directe resourceaanvragen of toegang tot het rapport van een andere tenant nooit getest. De waargenomen beperking heeft slechts betrekking op één actie.
Het voorgestelde antwoord is het vragen om geautoriseerd bewijsmateriaal over de ontbrekende activiteiten en het beoordelen van de daaruit voortvloeiende auditgegevens. Als het product het bekijken en exporteren niet kan scheiden, moet de koper beslissen of die beperking acceptabel is, in plaats van de rol te hernoemen en aan te nemen dat het risico is verdwenen. Dit is een fictieve aanbestedingsoefening, geen bevinding over EmailAuth of een genoemde leverancier.
Houd de aankoopconclusie begrensd
Een bruikbare conclusie identificeert vereisten waaraan door bewijsmateriaal wordt voldaan, vereisten waaraan niet is voldaan, beperkingen die door een eigenaar zijn geaccepteerd en tests die nog openstaan. Het maakt onderscheid tussen configuratiekeuzes en inherent productgedrag en belooft geen perfecte isolatie van een eindige testset. Het besluit kan worden genomen zonder te beweren dat elke toekomstige versie of configuratie gedekt is.
De catalogus vereist een toegangsmatrix en negatieve tests voor lees-, export-, schrijf- en levenscycluswijzigingen tussen tenants. Die originele tests blijven open. Beoordeling door menselijke specialisten, toepasbaarheid van bronnen, productieroutes, toegankelijkheid en vrijgave door de eigenaar blijven ook open. Dit ontwerp levert de beoordelingsmethode, geen aankoopadvies op basis van uitgevoerd bewijsmateriaal, en er is geen commerciële toezegging of toegangsverlening gedaan.