Een rolnaam definieert pas een machtiging als deze wordt vertaald in acties op resources. Bij een authenticatiedienst heeft het lezen van een rapport, het exporteren ervan, het goedkeuren van een wijziging en het uitvoeren van die wijziging verschillende consequenties. Bouw een kleine expliciete toegangsmatrix voordat u mensen aan rollen toewijst.
Begin met taken en bronnen
Vermeld voor elke tenant de domeininventaris, geaggregeerde rapporten, voorstellen, DNS -uitvoering en gebruikersbeheer. Bepaal wie het lidmaatschap mag lezen, exporteren, voorstellen, goedkeuren, uitvoeren en beheren. Klantmedewerkers kunnen hun eigen rapporten lezen; analisten zouden dit kunnen onderzoeken en voorstellen kunnen doen; aangewezen goedkeurders autoriseren de zakelijke impact; operators voeren goedgekeurde wijzigingen uit. Dit zijn voorgestelde rolgrenzen, geen claims over een specifiek product.
OWASP raadt bij elk verzoek aan om de minste bevoegdheden, standaardweigering en toestemmingscontroles uit te voeren. Een rol moet daarom worden geëvalueerd met het tenantbereik en de resource-identiteit, en niet als een globale Booleaanse vlag. Authenticatie stelt de opdrachtgever vast; autorisatie beslist of die opdrachtgever deze handeling nu mag uitvoeren.
Afzonderlijke goedkeuring van capaciteit
De technische toegang van een operator geeft niet automatisch toestemming voor elke bedrijfswijziging. De uitvoering binden aan het goedgekeurde voorstel en eventuele eisen inzake scheiding van taken afdwingen die de klant stelt. Als één persoon meerdere rollen bekleedt, noteer dan de overlap en de compenserende beoordeling ervan, in plaats van te doen alsof twee rolnamen twee onafhankelijke mensen vertegenwoordigen.
Houd het toestemmingsbeheer waar praktisch mogelijk gescheiden van routinematige analyses. Iemand die zichzelf uitvoeringsrechten kan verlenen, kan een nominale goedkeuringsgrens omzeilen. Bepaal wie krachtige rollen mag toewijzen, hoe deze toewijzingen worden beoordeeld en welke noodtoegang automatisch verloopt. Vermijd gedeelde beheerdersaccounts wanneer individuele verantwoordelijkheid vereist is.
Oefen de toegangsmatrix
Stel dat een lezer rapporten in tenant A kan bekijken, maar een export probeert uit te voeren waarvoor afzonderlijk verleende toestemming nodig is. Een succesvolle login en leessessie vestigen geen exportautoriteit. Daarnaast kan het zijn dat een analist die het account heeft verlaten nog steeds een oude sessie heeft; huidige lidmaatschap en resourcebereik moeten worden gecontroleerd voordat die sessie een ander rapport ophaalt. Dit zijn hypothetische toestemmingsgevallen, geen getest toepassingsbeleid.
Evalueer toegestane en geweigerde bewerkingen via de daadwerkelijke API, sessies, geplande taken en exports met behulp van geautoriseerde testidentiteiten. Voeg een geldige leesbewerking toe, zodat globale weigering niet wordt aangezien voor correcte toegangscontrole. Behoud de effectieve machtigingen, testcontext en waargenomen uitkomst; een nette matrix alleen toont geen handhaving aan.
Houd de levenscyclus zichtbaar
Leg de reden, het bereik van de tenant, de fiatteur en de beoordelingsdatum voor roltoewijzingen vast. Bij een functiewijziging verwijdert u oude machtigingen in plaats van alleen nieuwe toe te voegen. Offboarding moet lidmaatschappen en bijbehorende toegangspaden intrekken en vervolgens bevestigen dat de opdrachtgever niet langer artefacten kan ophalen of werk kan initiëren. Service-identiteiten hebben benoemde eigenaren en afzonderlijke levenscyclusbeoordelingen nodig.
Controleer de toestemmingsafwijking wanneer klanten, domeintoewijzingen of automatiseringsmogelijkheden veranderen. Vergelijk effectieve machtigingen, inclusief overgenomen groepen, met de goedgekeurde matrix. Als een klant een tijdelijke uitzondering nodig heeft, definieer dan de precieze werking, vervaldatum en beoordelingsrecord. Sluit de uitzondering wanneer de behoefte eindigt. Rollen zijn een onderhoudsmechanisme en geen eenmalig bewijs dat toegang veilig blijft.