How to manage access to your third-party service accounts
This document is current until 1 April 2018
When managing third-party service accounts, you must ensure:
- only the correct people in your team have access
- team members have account access revoked when they leave
- you identify who in your team is doing what and when (this is more important for some tools, like Amazon CloudTrail, than others like BrowserStack).
To securely manage account credentials
You’re likely to need a set of credentials to gain access to your third-party user account, for example passwords or secret access keys.
When managing these credentials, you must:
- keep the number of secrets you have to a minimum - this reduces the number of credentials to revoke when someone leaves GDS (passwords are particularly problematic secrets, other secrets such as secret access keys or OAuth tokens are more easily rotated)
- never use credentials associated with another individual
- encourage the rest of your team to avoid sharing credentials unnecessarily (technical limitations may mean this is sometimes unavoidable)
For accounts with organisation-level access
Often third-party services natively support organisation or team level access, for example the use of alphagov on GitHub. In these cases you should ensure only the appropriate individuals on your team have access.
With team or organisation-level accounts, where possible you should:
- create separate accounts for each individual rather than share credentials
- use a single-sign-on provider rather than create an account with a separate username and password - preferably use G Suite as it’s a core part of the GDS leaver process, which means that access to linked third-party services will be revoked automatically when someone leaves
- ensure that you have a documented process for removing individuals’’s access when they leave GDS
For accounts with individual-level access
When services don’t support organisation-level access, you may have to share individuals’ sign-on credentials.
Sharing individuals’ sign-on credentials can create risks as:
- you don’t always know who can access a service (particularly if users only access a service rarely because you can forget who has access)
- the last person with account credentials may leave GDS, making it impossible for others to access a service in future
To reduce these risks, you should:
- create an account using a Google Group email address rather than an individual’s email address
- set posting permissions to ‘public’ so your group can receive emails from outside GDS
- set viewing topic permissions to ‘all members of the group’ so only users with access to a service are able to view posts
- store passwords in your team’s shared credential store
- use two-factor authentication
- ensure you have a documented process for removing an individual’s access to the Google Group, credential store and for rotating credentials including any API keys
For GitHub accounts
You can use your existing personal GitHub account when you join GDS. Each GDS team should have someone (usually a technical lead) who is an owner and can grant/revoke access to their repositories.
For Logit accounts
Use Google Apps Marketplace when you sign into Logit (this is the only available option).