Et rollenavn definerer ikke en tillatelse før den er oversatt til handlinger på ressurser. I en autentiseringstjeneste har det forskjellige konsekvenser å lese en rapport, eksportere den, godkjenne en endring og utføre denne endringen. Bygg en liten eksplisitt tilgangsmatrise før du tildeler personer til roller.
Start med oppgaver og ressurser
For hver leietaker, liste opp domenebeholdning, samlede rapporter, forslag, DNS utførelse og brukeradministrasjon. Bestem hvem som kan lese, eksportere, foreslå, godkjenne, utføre og administrere medlemskap. Kundeansatte kan lese sine egne rapporter; analytikere kan undersøke og foreslå; utpekte godkjennere godkjenner virksomhetspåvirkning; operatører utfører godkjente endringer. Dette er foreslåtte rollegrenser, ikke påstander om et spesifikt produkt.
OWASP anbefaler minste privilegium, standard avslag og tillatelseskontroller på hver forespørsel. En rolle bør derfor evalueres med leietakeromfang og ressursidentitet, ikke som et globalt boolsk flagg. Autentisering etablerer rektor; autorisasjonen avgjør om denne rektor kan utføre denne handlingen nå.
Skille godkjenning fra kapasitet
En operatørs tekniske tilgang godkjenner ikke automatisk enhver virksomhetsendring. Forbind utførelsen til det godkjente forslaget og håndhev eventuelle pliktseparasjonskrav kunden vedtar. Hvis én person har flere roller, noter overlappingen og dens kompenserende vurdering i stedet for å late som om to rollenavn representerer to uavhengige personer.
Hold tillatelsesadministrasjonen atskilt fra rutineanalysen der det er praktisk mulig. En person som kan gi seg selv utførelsesrett kan beseire en nominell godkjenningsgrense. Definer hvem som kan tildele kraftige roller, hvordan disse oppgavene vurderes og hvilken nødtilgang som utløper automatisk. Unngå delte administratorkontoer når individuell ansvarlighet kreves.
Tren tilgangsmatrisen
Anta at en leser kan se rapporter i leietaker A, men prøver å eksportere som krever en separat gitt tillatelse. En vellykket pålogging og lesing etablerer ikke eksportautoritet. Separat kan en analytiker som flyttet fra kontoen fortsatt ha en gammel økt; gjeldende medlemskap og ressursomfang må kontrolleres før den økten henter en ny rapport. Dette er hypotetiske tillatelsessaker, ikke en testet applikasjonspolicy.
Evaluer tillatte og nektede operasjoner gjennom selve APIen, økter, planlagte oppgaver og eksporter ved å bruke autoriserte testidentiteter. Inkluder en gyldig scoped-lesing slik at global fornektelse ikke forveksles med riktig tilgangskontroll. Behold de effektive tillatelsene, testkonteksten og det observerte resultatet; en pen matrise alene demonstrerer ikke håndhevelse.
Hold livssyklusen synlig
Registrer årsak, leietakeromfang, godkjenner og gjennomgangsdato for rolletildelinger. Ved jobbbytte fjerner du gamle tillatelser i stedet for bare å legge til nye. Offboarding bør oppheve medlemskap og tilhørende tilgangsstier, og deretter bekrefte at rektor ikke lenger kan hente artefakter eller starte arbeid. Tjenesteidentiteter trenger navngitte eiere og separate livssyklusgjennomganger.
Gå gjennom tillatelsesavvik når kunder, domenetilordninger eller automatiseringsevner endres. Sammenlign effektive tillatelser, inkludert arvede grupper, med den godkjente matrisen. Hvis en kunde trenger et midlertidig unntak, definer den nøyaktige operasjonen, utløps- og gjennomgangsposten. Lukk unntaket når behovet slutter. Roller er en vedlikeholdsmekanisme, ikke et engangsbevis på at tilgang forblir trygg.