Hoe testen we de bescherming?
Een appnaam of verified publisher vervangt geen beoordeling van effectieve Graph-permissions en businessdoel. Nieuwe app en permission change lopen via review, testtenant of veilige testgegevens, change-ID en terugweg. Secrets komen niet in broncode, ticket of browsernotitie; ongebruikte grants worden pas na dependencycontrole ingetrokken.
vergelijk app object, service principal, oauth2PermissionGrant, appRoleAssignment, sign-in en workloadlog. Bewaar object-, app-, permission-, credential-, token- en change-ID zonder secretwaarde. Gebruik een appsecurityledger met app/service-principal-ID, verantwoordelijken, accounttype, redirect, permission, consent, credentialtype/expiry, API, afhankelijkheid en test. Applicatiedefinitie, tenantserviceprincipal, consentgrant, credential en effectieve resourcepermission zijn vijf aparte beveiligingsobjecten.
De review gebruikt de werkelijke service principal in de resource tenant, omdat daar consent en assignments leven. Een oude app registration zonder gebruik wordt niet blind verwijderd; sign-ins, tokens, API-logs en procesowner bepalen de afhankelijkheid.
Wat gebeurt er na de inrichting?
Rotatie wordt pas gesloten wanneer oude credential faalt en de nieuwe route dezelfde veilige testgegevens verwerkt. Nieuwe toestemming, een verlopen certificaat en het intrekken van toegang worden getest. Zo blijft een technisch werkende koppeling ook vanuit beveiliging uitlegbaar en beheersbaar.
Voor oauth- en appbeveiliging verbindt Radorfa de Microsoft 365-instelling aan account, apparaat, werktaak en testuitkomst. De klant ontvangt voor oauth- en appbeveiliging de werkende afspraak, testuitkomst en open aandachtspunten.