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.
