There are few things as liberating as a thorough spring cleaning. We notice accumulation of unnecessary “stuff” – clothes we no longer wear, household items we no longer use, furniture we don’t need, and much more. Most of us do nothing about it; in fact, we keep accumulating clutter. Then comes the point when the clutter’s in the way of everything we do. And finally, when we’ve had enough, we decide to act.

Then, it’s a mad dash of cleaning and organizing, followed by a sense of euphoria. For a few weeks we love how much easier it is to get things done and find what we need around the house. We vow to keep things organized, but inevitably our tendency to accumulate stuff returns.

This process is, unfortunately, not unique to just your house or your desk. You can draw a parallel to your infrastructure. It’s critical you routinely take a look at the accumulation of identity privileges in the dusty corners of your private and public cloud.

It’s Time to Get Rid of the Privilege Clutter and Safeguard Your Infrastructure in the Process!

Chances are there are tens of thousands of identity privileges in your environment that haven’t been used in the last 90 to 180 days, or longer. And those privileges, in many cases, are classified as high-risk privileges.

Begin mitigating this risk by following four basic steps:

1. Remove inactive identities or groups
If the inactive human or non-human identity is no longer with the company or no longer needs access to the authorization system, then the easiest thing to do is to completely remove them from the environment/ authorization system. The same goes for inactive groups.

We use the following criteria for group ‘inactivity’:

– The group has no members (identities)
OR
– None of the group members/identities have performed any actions in the last 90 days.

2. Convert inactive identities or groups to “read-only” status
If you are uncertain about the status of the identity or group or are simply uncomfortable deleting them, you can always mitigate the risk by assigning “readonly” privileges. A perfect example would be a human identity with a fair number of high-risk privileges who no longer actively performs actions on resources in your environment, but who needs access to the authorization system.

The same rational might apply to a group that’s been inactive for at least 90 days but may still need access to the authorization system to perform read-only functions.

3. Remove ALL “high-risk” and “delete” privileges
If you expect the inactive identity or group to resume some level of activity on resources in the near future, you can revoke (or what we like to refer to as “right size”) all “delete” privileges from inactive identities, further mitigating the risk of an identity misusing a high risk privilege down the road, wreaking havoc on your environment in the process.

The idea of tackling the “identity privilege clutter” in your environment might at first seem daunting. Sure, you will have the urge to put it off just a bit longer, but it’s important to suppress this dangerous desire. The key is to first start with the easy-to-clean low hanging fruit and to begin by reorganizing the inactive identities and groups within your environment. Let’s explore a little further.

One common cause of identity privilege clutter is human identities that have either left the company or moved to another group. Then there is the case of non-human identities, like service accounts or bots, that are no longer required and have long since been decommissioned. Regardless of the inactivity’s cause, these identities retain a set of privileges, allowing them to perform actions—often high-risk—on critical resources within your environment. This means they pose a significant—albeit completely avoidable—risk to your organization.

Here is a sample table of “Delete” actions in an Amazon Web Services environment:

Platform/Service	Action/Privilege	Impact
AWS: EC2	TerminateInstances	Kills the compute instances
AWS: ECS	DeleteCluster	Kills the compute instances
AWS: EKS	DeleteCluster	Kills the compute instances
AWS: S3	DeleteBucket | dynamodb:DeleteTable | rds:DeleteDBInstance | glacier:DeleteVault | elasticache: DeleteCacheCluster	Delete the storage account/container

4. Reduce the scope of your environment
Lastly, you’ll want to consider downsizing the scope of resources to which these identities have access. For example, maybe you have an inactive human identity whose privileges you don’t necessarily want to revoke. As a safeguard you limit the type of resources (e.g. non-critical) on which they can perform a set of “delete” actions.

Be Clean, Be Safe, Be Happy
Let’s revisit the important takeaways: Your infrastructure spring cleanings need to be frequent. With procrastination comes a high risk to your organization. Use our recommended guidelines for inactivity—or tweak them to fit your needs—but address them regularly. The steps we discussed above are a great place to start and should make beginning the process much less daunting. Enjoy the wonderful post-cleaning euphoria and be sure to stay tuned for our next blog entry where we discuss how to clean your active identities and groups. Until then, scrub-a-dub-dub.