Skip to main content

The GDS Way and its content is intended for internal use by the GDS and CO CDIO communities.

Principle of Least Privilege

The principle of least privilege involves setting up user accounts so they can only access and use the information they need for specific tasks. This can also apply to processes and individuals who might have to switch between normal access and the increased access of a superuser account as part of their work.

Examples of privileged or higher security access are:

  • root access
  • updating operating systems
  • performing “sudo” operations
  • accessing high 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 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 is set to no more than 12 hours, and/or terminates when the user logs out of their laptop
  • establish an audit trail for the use of privileged access

Examples

For human-readable secrets, such as a username and password, you should set up a separate secret or password manager. An example of a secrets manager is LastPass which you can use to store system-critical credentials, and restrict the number of people who can access this store according to their roles in the team.

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 12 hours. 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.

Further Guidance

This page was last reviewed on 13 July 2021. It needs to be reviewed again on 13 January 2022 by the page owner #gds-way .
This page was set to be reviewed before 13 January 2022 by the page owner #gds-way. This might mean the content is out of date.