Authorisation Management concerns which identity has access to what functionality, both from a functional (platform) and operational (DevOps) point of view. With the least privilege principle, only necessary access to data and functionality will be given.
Role based authorisation
Authorisation will always be given to a role or a group of roles, never to a specific identity, where a role can be defined as a group of identities that have a specific business function. When a certain person or system needs authorisation, the related identity will be added as a member of a role that contains the appropriate authorisations.
Identities are assigned membership to a role based on the least privilege principle, meaning that as little authorisation is given as needed to strictly use the needed functionality and not more.
Preferably roles are defined in a top-level directory provider, like Azure Active Directory, where these roles are assigned application-specific execute rights. When using a top-level directory provider is not possible, it is allowed to use application-specific providers.
Separation of concerns
Role definition and membership can only be maintained by identities that have an administrative role and as such are a member of an administrative role. Every role assignment related to technical access will be reviewed by a person, not being the person assigning the role.
When an incident occurs that requires more authorisation to solve, this authorisation is given on a temporary basis, where membership is revoked as soon as the incident is solved or solving the incident is not considered to be an actively pursued goal.
Environment specific authorisation
Authorisation can differ between production, acceptance and test environments. Where production and acceptance should use the same authorisation scheme that is as restrictive as operationally possible, the test environment can implement a less restrictive authorisation scheme, providing means to do extensive testing, debugging or simulations.