Here’s a spooky Halloween tale sure to send shivers down the spines of even the most hardened DevOps and security engineers. Not to go all FUD on you – well, mainly the fear part – but there’s a creeping menace meandering silently within your digital infrastructure, ready to strike at any moment.
They’re “zombie” service accounts – ‘tis the season! – which are often set up to provide a workload or application access to a service, and they’re drifting dormantly across your cloud and on-premises environments. These lurking phantoms are inactive, undermanaged, and over-permissioned – and ripe targets for attack.
Creepy, isn’t it?
For years, the biggest cybersecurity concern for organizations has revolved around human identities, due to threats like phishing and credential stuffing. However, in today’s cloud-first, API-driven landscape, it’s the service accounts that are becoming an escalating concern.
Service accounts essentially function as non-human identities. They’re meant for instances when a workload, such as an application, needs to access resources or carry out actions without human intervention.
We’ve extensively discussed the dangers associated with unprotected communication between workloads, particularly the risk of exposure of credentials and the neglect of secrets rotation. (In fact, according to a recent Microsoft study, more than half of organizations have user-managed keys for service accounts within Google Cloud that are not rotated, and more than 45% of organizations have access keys that have not been rotated for at least six months in AWS.)
But service account sprawl, often a byproduct of a lack of a workload identity strategy, is an underappreciated risk.
The persistence of these unused or rarely used service accounts is not merely a question of hygiene but represents a significant security concern. The Microsoft study, titled “2023 State of Cloud Permissions Risks Report,” found that nearly 80% of workload identities eventually become idle, double the percentage reported in 2021.
The situation becomes more problematic when you consider the growing disparity between the permissions given and the permissions actually utilized. Currently, workload identities are employing less than 5% of the permissions they’ve been provided.
This indicates that many workloads have capabilities they don’t actively need. Yet every unused permission within a service account is a potential point of entry or exploitation for malicious actors, or a risk of accidental exposure. In the event that a service account is compromised, either by an external attacker or an inadvertent internal action, these permissions can be a ticket to sensitive data leakage or lateral movement throughout your systems.
Meanwhile, from an administrative and operational efficiency standpoint, if service accounts tied to workloads have excess permissions, it becomes challenging to manage and track them. It’s hard to distinguish between necessary and unnecessary permissions, especially when the service account’s role or function evolves over time. Maintaining these inactive accounts consumes already starved resources, from the computational power to the human time involved in their management.
So, how have we gotten here?
Rapid Expansion and Scale
As organizations migrate and expand their cloud operations, there’s often a rush to set up identities for each new workload, leading to the creation of more identities than are actually necessary.
Irregular Audits
Without systematic checks, dormant workload identities can easily slip under the radar, especially when organizations deal with a vast number of them.
Overprovisioning
In a bid to ensure uninterrupted services, identities are often endowed with more permissions than they need. Over time, this can lead to a buildup of inactive workload identities that still possess high-level access rights. The Microsoft study found that over 50% of identities are considered “super admins,” defined as users or workloads that have access to all permissions and resources.
Lack of Centralized Control
It’s crucial to have a unified platform or system in place that offers visibility across all service accounts, ensuring that they’re aligned with the organization’s security policies and best practices. This centralized point of control allows for regular audits, fine-tuning of permissions, and timely deprovisioning of unnecessary accounts, thereby reducing the risks associated with inactive service accounts.
6 Steps You Can Implement to Rein In Inactive Service Accounts
Addressing the technical challenge posed by inactive service accounts necessitates a tactical and strategic approach.
As with any machinery, regular maintenance, timely updates, and systematic checks are crucial to ensuring optimal performance and security. Inactive workload identities are analogous to deprecated components within this machinery – components that, if not addressed, can lead to potential system failures or vulnerabilities. Given the crucial nature of these identities, it becomes imperative for organizations to adopt a proactive approach to manage them. This should include:
1) Regular Audits: Schedule routine checks of your workload IAM infrastructure. Use automated tools to identify and flag any workload identity that hasn’t been active for a defined period. For instance, if a workload identity hasn’t been used for 90 days, it may be ripe for review or deactivation.
2) Implement Least Privilege Principle: Rather than overprovisioning, assign only the minimal necessary permissions to service accounts. As workloads evolve, permissions can be adjusted, ensuring that identities are never burdened with more access rights than they genuinely require.
3) Use Conditional Access Controls: Rather than granting indefinite access, utilize time-based or state-based controls. For example, a workload identity might be given permissions for a specific project duration, after which they’re automatically revoked.
4) Monitor Workload Behavior: Utilize AI and machine learning tools to monitor and understand typical workload behavior. Anomalies can quickly flag potential issues, allowing for rapid response.
5) Manage Lifecycles: Ensure there’s a well-defined development and deployment lifecycle for every workload identity, from creation to deactivation. Establish clear protocols for when and how an identity should be retired.
6) Training and Awareness: Keep your DevOps and security teams aware of the dangers of inactive workload identities. Regular training can help teams understand the importance of diligent machine-to-machine IAM management.
Who You Gonna Call? Workload IAM Platforms
If you really need to call in the heavy hitters, Workload IAM platforms are like the skilled “ghostbusters” of the zombie service account realm – managing access from client workloads connecting to server workloads.
Instead of you needing to create a service account for each workload, Workload IAM platforms create a trust relationship with the desired service (and the service account) and then can manage access for all the applications that require it. This approach ensures a clear trail of which applications accessed a service, eliminating the need for an excessive number of service accounts being hard coded into workloads that aren’t actively using them.
This helps to give you:
- Sprawl Control: Applications no longer need to hard code sensitive credentials, or even request long-lived ones. Credential rotation is automated because client applications get a dynamic credential regularly.
- Access Policy Management: By providing a centralized approach to managing access to sensitive services and data, you can avoid overprovisioning.
- Automated Audits: A detailed, centralized log of access requests between client and server workloads gives you a clear oversight, ensuring you always have a grasp on active and inactive service accounts
- Lifecycle Management: From creation to eventual retirement, the entire journey of an identity is mapped and managed, ensuring timely deactivation of those no longer in use and empowering you to confidently build your next-generation of applications.
So as you approach this Halloween, beware…because there might just be some forgotten-about, overprivileged skeletons in your digital closet. Boo!
For more information about Aembit can help, visit aembit.io.
