A service account is a privileged account that belongs to – and is used by – software and machines. Traditionally, credentials are static, and are rarely changed because of the administrative overhead involved. Service accounts often have access to multiple resources, and it’s not uncommon for them to be overprivileged. Service account passwords are often shared among IT or development teams and re-used across multiple systems, and service account sprawl is common.
Service accounts are commonly configured with a “set it and forget it” mentality. If they are compromised, service accounts provide a means for attackers to quickly move laterally across the environment, accessing multiple systems with a single password. Their existence represents a significant potential vulnerability in any enterprise environment.
Securing cloud infrastructure requires dynamic service accounts with specific, time- and function-limited access. Development teams often leave service account keys behind in code, since doing so facilitates easier testing. And would-be-attackers are constantly scanning code repositories for these keys.
What’s needed is a mechanism for delivering time-limited access. With time-limited keys, credential access can be checked out like a book from the local public library, used only for the time that it’s needed, and checked back in, when it will expire. It’s also possible to deliver time-limited access automatically, relying on a credential-less approach in which access privileges are granted and revoked at predetermined times established by an administrator or security team member.