The Service Accounts Conundrum: What They Are and How to Secure Them
Often, when people refer to non-human identities and access, they instantly think of service accounts—and for good reason. While there are many different programmable access credentials like API keys, OAuth apps and SSH keys, service accounts are a bit different. Their definition is very vague, their use is unstructured and, because of that, securing them is even more challenging.
Google’s definition of a service account is a special kind of account typically used by an application or compute workload, rather than a person. As a non-human access credential, service accounts are mostly used to allow access between apps, services and tools for automated processes within business environments.
Use of Service Accounts Exposes us to Threats (Looking at you, Okta)
To understand the risk of service accounts and how to properly manage and secure them, let’s first identify the two types of service accounts. The first are accounts supported inherently by the platform, i.e., Google Cloud Platform (GCP) or Snowflake. In these platforms, you can set up service accounts as part of a structured process and manage them in that way. The second type is what we in the industry see more often, where there is no built-in support, like Amazon Web Services (AWS) or Salesforce. In such platforms, one can create service accounts, but since the platform has no inherent support or structure, more security issues and risk are introduced.
Service accounts act as “identities” and are given access to vast amounts of data. However, since they don’t require any human supervision, they aren’t protected by standard identity security controls, i.e., multi-factor authentication (MFA). Not to mention that service accounts don’t have many, or any, restrictions and are likely highly-privileged accounts–which makes them particularly lucrative to threat actors.
Unfortunately, we’ve seen this exact scenario unfold in the last few months. Just recently, identity and access management company Okta was breached when attackers used a leaked service account to access Okta’s support case management system and viewed files uploaded by some customers. No more than two weeks later, a Zoom flaw enabled the hijacking of service accounts with access to potentially confidential information. The vulnerability, based in the Zoom Rooms feature, affected mostly Zoom tenants using email addresses from large providers like Outlook and Gmail.
Best Practices to Minimize Risks
So how do you stay ahead of these potential risks without blocking business agility and processes? Below are some practical tips that you can use today to reduce your exposure to service account exploits:
- Grant minimal permissions: Managing permissions on a service account is tricky and depends on the type of account you’re dealing with. Some services allow granular configuration of permissions, even going down to the API level, but others don’t—and only have basic read/write dichotomy. It’s important to choose the right type of account and grant the most restrictive permissions that would still allow the service account to do its job. Additionally, regularly monitor and differentiate between service accounts with different levels of permissions (high/medium/low), and subject them to security controls accordingly.
- Separate service accounts per microservice: Create service accounts for each individual application. Don’t abuse service accounts for several different services or applications, even if they require the same set of permissions.
- Monitor behavior: Service accounts must behave in a predictable manner: they should always call the same APIs (and in a predetermined order), use a designated set of IP addresses and begin their work on a set time (if working synchronously) or react to the same events (if working asynchronously). Therefore, employing regular behavior analysis should be easy—if they deviate from the expected behavior, the service account should be disabled and looked into.
- Restrict access in other ways: Compared to the previous point, static methods of bounding the usage of a service account should also be employed; restrict IP addresses from which the account can be used, determine the days/times in which long-term credentials can be exchanged for short-term credentials and assign an expected set of APIs that the account is expected to call.
- Determine permission sets for the owner: Designate an owner responsible for managing and maintaining the account. This owner should be the only one able to generate new credentials or access. Additionally, they should also be in charge of monitoring the account’s activity and behavior, as well as regularly rotating its credentials and updating security controls. Changing permissions of a service account should go through an objective person who is able to question the need for additional access, similar to how increasing a user’s access happens.
Service accounts certainly need to be better protected. Unfortunately, it takes some worse-case scenarios to see how important this type of security is.
