Service account standards

Service accounts for Software-as-a-Service (SaaS) applications have high levels of access and are shared between multiple people — a tempting target for attackers. But service accounts aren’t just a source of security risk. They can also slow down engineering teams. Laggy approvals for access, flaky integrations, and risky manual changes are speed bumps on the path to delivering value. This post discusses standards you can introduce at your organization to tame service account management.

What are service accounts?

When you try out a new SaaS application, you might register with your email, password, phone number, and enable 2FA. Next, you might set up SSO for your team using OAuth, or SAML. This creates access for people in your organization to access, but if you want to integrate other software, or delegate trust to multiple people, you’ll need to create a service account. Service accounts look like regular users to the system, but they don’t belong to a single human being (e.g. developers@example.com).

Service accounts are required when accounts don’t have an obvious owner. The first user that signs up may have full administrative privileges, or be sent important announcements (e.g. the AWS root user). Service accounts also enable integrations between cloud-based services, where you need to grant code access in the same way that you might grant access to a human. As an example, see the API documentation for Okta. If you look at a list of users for many software services, you‘ll see both human accounts and service accounts, and service accounts usually have elevated permissions. At larger organizations, these functions are more appropriate for a group than an individual.

Accounts that aren’t mapped to real people create operational challenges because they rely on security information that makes sense for an individual, not a group. Email addresses, passwords, phone numbers, and even hardware keys are human-centric, as are authentication practices like secret questions, account reset via email, and 2FA via SMS. If you build software that integrates numerous cloud-based systems, you have a trail of shared passwords, MFA exceptions, and API tokens that are difficult to manage because of these limitations.

Email addresses

Most service accounts use an email address to deliver security sensitive information like password reset emails and security notifications. If you create an email account for service accounts (service-account@example.com), you now have to manage two service accounts — one for the service, and one for the email service provider. More shared passwords means more operational security tasks.

Instead, many email providers have groups (e.g. Google Groups, Office 365 Groups) that can be configured to receive public email. Access to the emails can then be managed with identity automation controls rather than shared passwords.

Creating a new group for each service may be a source of toil. As a shortcut, you can group similar services into a single access group using a standard naming convention with the plus sign:

<team-name>-service-accounts+<service-name>@example.com

These standard names can be useful if, for instance, you’re required to create service accounts in your SSO directory. At a glance, you can see what this non-human user has access to and who it belongs to. It could also facilitate automation, which is useful when gathering compliance evidence. Emails to these addresses are often important, and could be routed to a SIEM for alerting and auditing.

Passwords

Many password managers offer team features, where groups of individuals can be granted access to stored passwords. Examples include 1Password, LastPass, and DashLane. If you need to use your service account to log in via a web browser, password managers are an excellent choice to protect against browser-based phishing threats by leveraging browser plugins that ensure the passwords are sent to trusted domains.

Password managers should be integrated into standard service account generation practices. The password generation formula, metadata information, and access control should follow documented guidelines. Not all shared password managers are equal — some support automated provisioning of users and groups, are more easily tapped for audit logging, or offer API access and automatic credential rotation. Make sure to consider both individual and group use cases when selecting the password management platform for your organization.

MFA

Service accounts that are used for “owner” accounts can turn on MFA, but most MFA features are designed to be used by a single person. If it’s “something you have”, then it won’t work for service accounts that are used by multiple people.

For TOTP MFA — six-digit codes synced between different devices — you can either store the MFA seed in a password manager, or have each service account owner store it on their device. Either way, you may still need to rotate this value, or the password, or both, to effectively change the access control after the values have been accessed. If you have administrators store the secret locally, you’ll need to have solid onboarding/offboarding and “I got a new phone” processes in place to keep access consistent.

If MFA uses SMS, you can use an access-controlled shared SMS inbox like Google Voice. SMS has a weak security track record, although SIM swapping is less of a threat for these services than for individual phone accounts. This pattern would also reduce the risk of having administrator turnover, since there’s no secret that can be stored offline.

High-security hardware tokens only make sense for service accounts if they support multiple tokens. Keep in mind that syncing these keys with the current list of administrators is an operational challenge as your organization scales and changes.

API Tokens

Service accounts used for integrations typically authenticate with long pseudorandom API tokens. These belong in secret stores like Hashicorp Vault or AWS/Google Secrets Manager, alongside other service credentials like database passwords or OAuth tokens. This gives you a consistent interface to implement your access control, auditing, rotation, etc.

When generating service account API tokens, you can often plug the value into the other side of the automation and not store it anywhere else. Consider — will you need the value later, can you just generate a new token?

Credential rotation

Secrets work best when fewer people can access them. Service account credentials, whether they are passwords, API tokens, or certificates, will eventually need to be changed. While each system will have a different set of constraints, the first step for systems that don’t currently have regularly rotated credentials is to start with a scheduled documented manual process.

If you have a good inventory of service accounts and a documented process for rotating their credentials, you’ll be in a position to automate and reduce the operational toil and fragility of this important but time-consuming activity.

Permissions

Service accounts and regular users have different use cases. It can be challenging to model permissions with role-based access control systems that are designed for people. If there are only a few roles (e.g. administrator or user), you may have service accounts with too much access. Where possible, define tight access controls for service accounts used for integrations, since their behavior should generally be pre-determined. The more fine-grained the access control mechanism, the more you can reduce privilege for service accounts. Consider strict security controls like approvals and critical alerts for owner accounts, since their use is often limited to rare “break glass” scenarios.

Automating cross-departmental functions helps organization scale. Connecting systems — productivity software, customer success platforms, data warehouses, cloud infrastructure, identity providers — often means using the proverbial duct tape and rubber mallet of service accounts. By setting organizational guidelines that are sensible and consistent, you can make sure that these load bearing joints of your trust architecture stay resilient.