Access Management

Overview

We operate under the principle of least privilege. This means that you should only have access to the services and functions that you need to do your job and nothing more. This approach limits the damage that can be done in an event that someone’s access is compromised.

Additionally, we use individual accounts for access wherever possible to make it easier to audit people’s access, avoid the risks associated with shared password and help with offboarding.

Finally, if we need to share passwords, we recommend using a Password Manager or other secure sharing tools to minimise the risk of password leaks.

Managing Access to Servers and Services

If you are managing access to a particular service, environment or server, then you are responsible for maintaining the security of the service and the data within. You should be following the principle of least privilege to minimise the security risks associated with improper access.

If someone requests access to a service, consider what level of access they need to complete the task they are working on. It is tempting to give people full access (administrator rights) to save time, but this creates a significant security risk if their account is compromised. Additionally, having unnecessary permissions invites human error by allowing people to configure functionality that they shouldn’t have access to. You should always be aiming to only give people enough permissions to do their job and nothing more.

info

This is particularly important when managing access to ecommerce platforms, especially production environments, as they contain personally identifiable information about our clients' customers. A data breach can cause considerable damage in the form of reputation and monetary cost to us, our clients and their customers.

In practice, we use three levels of access on our projects:

• Development access

  • This includes the ability to use and configure the features required when working on the project, but won’t allow any administrative actions. Most of the developers on the project will have this level of access.

• Privileged access

  • This includes all of the above responsibilities and the ability to perform administrative actions, including the ability to manage access to the service, configure the service and perform destructive operations. This level of access is reserved to tech leads.

• Elevated/Owner access

  • This includes all of the above responsibilities and the ability to perform billing related activities, such as managing payments or subscriptions and installing additional components. This level of access is normally not required as part of a project and is therefore reserved to our clients. However, in some circumstances elevated access can be temporarily given to the tech leads to perform a specific task.

Using Shared Accounts

Shared accounts create a security risk by making it difficult to control who has access to the account and audit the actions performed on behalf of the account. Additionally, they create a management overhead when team members join or leave projects. Therefore, shared accounts should be avoided whenever possible and users should be configured with individual accounts as a preference.

However, in some cases it may be impossible or impractical to create individual accounts. In that case, you should create a dedicated account for the purpose, which can be shared with the relevant people.

Finally, save the account credentials in a Password Manager and share the entry with the relevant people (either individually or using a shared folder).

Sharing Passwords

If you need to share a password with someone, internally or externally, it is important that you do so securely to minimise the risk of compromised access.

When sharing sensitive information externally, make sure that the information is encrypted in transit (don’t share passwords in plain text). You can use one of the following options, in order of preference:

• Password Manager

  • Where possible, share through shared password manager.

• One Time Secret

  • This service allows you to send an encrypted message that can only be read once. Paste the information into the provided box, enter an autogenerated passphrase and select a lifetime of 1 day or less. Send the secret link that the service to the recipient, then send the passphrase separately. Ideally, you should use different communication methods for the link and passphrase.

• Password protected .zip

  • ⚠️ This method should only be used if other methods are unavailable.
  • Save the sensitive data to a text file, then create a password protected .zip archive including that file and using an autogenerated passphrase. Send the .zip archive and the passphrase to the recipient separately. Ideally, you should use different communication methods, e.g. send the .zip as an email attachment and the passphrase via Slack.