Securing Cloud-Based Service Accounts

42% of data breaches result from stolen credentials, which is why it’s critical to secure enterprise service accounts. Traditionally, these accounts use static credentials and are an often-overlooked vulnerability that exists in nearly every IT organization. They provide privileged access between software and processes, many of which run through automation. 

Configuring service level accounts with a “set it and forget it” mentality — and static passwords that grant high access levels — is an all-too-common practice. These passwords are often shared and reused among the IT team across multiple systems. If compromised, this provides a gateway for attackers to burrow deep into the IT ecosystem. 

In this article we explore how to tame service accounts by leveraging cloud PAM (privilege access management) to remove the standing risk while still maintaining their much-needed functionality.

Changing Times

In modern DevSecOps, service accounts can no longer be a situation where you set up the account and walk away. Securing cloud infrastructure requires dynamic service accounts with specified access. The ephemeral cloud model allows resources to be created and destroyed on the fly; thus, it requires more advanced management. Cloud access needs to be flexible — like the cloud is — and not merely persistent. The use of a cloud-based PAM  eliminates static access, reducing the overall risk of attacks while tracking the utilization of privileged access.

Secrets Management

A comprehensive PAM solution integrates with a secrets management tool allowing for time-limited credentials and keys. Secrets management is an essential aspect of secure coding in the cloud because of the challenges presented by it. Different credentials and keys provide access for service accounts to cloud resources. Some allow access to a given resource, while others bestow the proverbial “keys to the kingdom,” opening up deep access throughout the entire organizational cloud. For this reason, bad actors are continually scanning code accessible online, looking for privileged access credentials.

When these credentials remain in code, they create a huge vulnerability. Cloud privileged access management, when done right, ensures these secrets are not at risk. The best secrets management solutions generate and decommission secrets and keys automatically. Even if they remain in code, they work only for a short period before becoming inert. This change dramatically decreases the overall risk and narrows the potential damage from stolen credentials from code. 

Controlling Code

Developers fall prey to leaving secrets in code because it makes testing easier. But the convenience isn’t worth the risk.  Keeping secrets in code leaves you open to pivot attacks — a type of attack where the credentials are re-utilized to traverse the IT ecosystem and access additional resources. 

According to OWASP, hard-coded credentials are a high-impact vulnerability and likely to be exploited. This vulnerability is not only easy to catch, but simple to remediate. Peer code review and SAST (static application security scans) testing can help identify secrets left behind in code. These credentials can then be replaced with stronger access controls, such as rotating keys or dynamically provisioned accounts.

Read more about securing the DevOps process to safely leverage the cloud for agility and velocity.

Time Limiting Keys

Properly managed service accounts (or any account for that matter) make it harder for bad actors to get a useful key. Time-limited credentials eliminate hard-coded credentials, even during testing. Should a bad actor acquire the credentials, they only last for a set time before expiring — forcing the use of a new key.

A crucial part of this process is credential check-ins and check-outs. Comprehensive secrets management software will rotate keys or passwords associated with identities ensuring that they cycle out after a set period. This process forces a re-authentication to check out privileged credentials, which creates an audit trail of who had what privileged access and when. Checking-out assures an end-to-end access trail gets created for future audits.

More Than Access

Staying ahead of threats in the cloud takes more than mere secrets rotation. Part of protecting service accounts involves checking out access, an essential aspect of Zero Trust. By default, resources should block all privileged access, called Zero Standing Privilege (ZSP). When privileged access is required, the identity can request it. A compromised account is completely worthless with Zero Standing Privilege — even if acquired while the credentials are still active.

Achieving ZSP requires a full-featured cloud PAM solution that oversees access across an organization’s entire IT ecosystem. It contains a listing of all available access, where it has been granted, and then uses artificial intelligence to make risk-based decisions on granting further access. So when any identity requests access, the software reviews the potential access risk and impact based on contextual identity information, such as roles, positions, and groups to make access decisions. If the risk is within tolerable limits, access is granted for a set period and then auto-decommissioned. If the risk level is too high, it escalates to a human for review. All of this leads to an auditable trail that accounts for all access granted and significantly limits an attack’s scope, if it were to happen. 

Rethinking Service

With a cloud-native PAM solution, managing complex service accounts and access in the cloud no longer has to be a challenge. Automation helps to drive time-limited access and permissions for  human and machine-based identities. Time-limited access and Zero Standing Privilege ensure that the right amount of access is granted only for the appropriate time period. All of this helps reduce overall risk exposure and the potential damage that can occur from a breach.

To learn more about how Saviynt’s Cloud PAM solution can help secure your vulnerable service accounts, read Cloud PAM for Robust Cloud Security