Principle of Least Privilege
The principle of least privilege is succinctly defined as “Every program and every privileged user of the system should operate using the least amount of privilege necessary to complete the job.” It requires you to consider what permissions actors in your system need. For robotic or computer actors, like your deployment pipeline, this can be fairly easy to scope. Likewise, your end-users will have a clearly defined set of permissions they need to use your service.
All access provisioned for use within GDS must be provided on a least privilege basis.
Examples of privileged or higher security access are:
- root access
- updating operating systems
- performing “sudo” operations
- accessing secret credentials
- committing to repositories
You should use the principle of least privilege if you:
- need to grant required access rights to different users according to the nature of their job
- want to use different permissions for day-to-day tasks from those required for security-critical (privileged) tasks
- want to limit collateral damage when a normal user account gets compromised
Your team should:
- make users aware of this policy and be required to confirm their understanding of their access privileges and related conditions of use
- have a process for them to request changes to access as needed
- define roles for users and grant required privileges, or access rights, for those roles
- create the roles or credentials with the least possible privilege, with only necessary permissions required for normal users to perform their day-to-day jobs
- use the role or credentials with the least possible privilege as the default option
- use just-in-time (JIT) access provisioning to grant users an on-demand, time-limited privileged role or security token to access the privileged resources
- make sure session time of the privileged access (in non-development environments) is set to no more than 30 minutes, and/or terminates when the user logs out of their laptop
- establish an audit trail for the use of privileged access
- ensure approval and use of privileged accounts is kept to the absolute minimum necessary for a user to perform their job role
- in cases where JIT access is not implemented for users with privileged access that have critical business impact, implement a documeneted periodic review (cadence to be defined) of the need to continually have these privileged access granted to confirmed users
- have a Joiners, Movers and Leavers process, where line managers (or equivalent) arrange for privileged access to be removed (SLA to be defined) where it is not required. See this NCSC guide on identity management for more information.
It’s important to recognise opportunities for privilege creep / accumulation and to design in suitable processes for preventing it.
Examples
For human-readable secrets, such as a username and password, you should set up a separate secret or password manager.
If you’re using the gds-users account to log into your AWS accounts, you should assume a read-only role by default. You should only assume an admin role when absolutely necessary for a specific task. You should set up the admin account so that the session timeout is less than 30 minutes. You should send the audit trail of admin access to the Cyber Security team. Use the Cyber Security Slack channel (#cyber-security-help) to set up the audit trail.