Regular cleanup is part of all account administration and security best practices, not just for cloud environments. In our blog post on identifying inactive identities, we looked at the APIs offered by IBM Cloud Identity and Access Management (IAM) and how to utilize them to obtain details on IAM identities and API keys. Some readers provided feedback and asked on how to proceed and act on identified inactive identities.

In response, we are going lay out possible steps to take. We show how to find and revoke existing privileges and what to consider. Moreover, we discuss how the different identity types can be removed from an account. We also provide some directions on how to script and possibly automate these administrative tasks:

Recap: Inactive identities

IBM Cloud Identity and Access Management (IAM) supports different forms of identities. They include users and service IDs—both with associated API keys—as well as trusted profiles. When such an identity or an associated API key has not been used to authenticate for a set time, it is considered inactive.

IBM Cloud IAM provides functionality to create reports on inactive identities. By default, identities are considered inactive when they haven’t logged in or been in use in 30 days. When creating a report by utilizing the API or an SDK, you can specify other time frames (e.g., 90 days).

Inactive identities pose a security risk because they might be no longer maintained and be easier to attack. To improve security, you should revoke access privileges from inactive identities and maybe even entirely remove them from the cloud account.

There is, however, an operational risk with special identities that are only used for quarterly or annual processing (which, in our opinion, is bad security design). If cleaned up, their associated tasks may fail. This scenario could be addressed by keeping tabs on how inactive identities and their privileges are cleaned up.

Automated cleanup

Acting on discovered inactive identities could be done manually, but should be automated for efficiency and improved security. Both manual and automated cleanup could follow a process like this:

1. Generate and retrieve a report on inactive identities for the desired date range.
2. Check the reported identities against a list of exempted IDs.
3. Loop over each non-exempted identity and remove it from all IBM Cloud IAM access groups. Also, make sure that no directly granted permissions exist.
4. Go over found API keys and delete them.

For all steps, log the findings and actions taken for audit and improvements.

Depending on your corporate policies, you might want to clean up monthly or quarterly. When triggering the report generation in the first step, you can specify the duration (the range in hours) for what to consider as inactive. To avoid the risk of shutting down important identities, you should maintain a list or database with identities that are excluded from cleanup (Step 2 above). That list could also be used to distinguish between different policies like monthly or quarterly checks.

When processing each found inactive identity (e.g., users, service IDs, trusted profiles), it is fairly easy to revoke assigned privileges. IBM Cloud IAM provides a REST API with a DELETE to remove an IAM identity from all associated access groups (Step 3 above, see screenshot below).

If following best practices, permissions should only be assigned through access groups and not directly. You can verify this rule by retrieving the list of directly granted privileges for the IAM identity. If such a privilege (access management policy) is found, there is an API to delete that policy (Step 3). You can see our blog post “IBM Cloud security: How to clean up unused access policies” for additional information.

The report on inactive identities also includes a section on API keys. API keys are associated with either a user or service ID. The question is how soon to clean them up by deleting the API key. Similar to removing privileges from an identity, deleting an associated API key may break applications. Decide what is best for your cloud environment and meets corporate standards.

The above cleanup steps can be scripted and run manually. You could also automate the cleanup by taking an approach similar to what we describe in this blog post on automated data scraping. Use IBM Cloud Code Engine with a cron subscription to trigger execution on set dates or intervals:

Users, service IDs and trusted profiles

Above, we discussed how to revoke privileges from inactive identities. To further clean up the account and enhance security, you should consider deleting unused service IDs and trusted profiles and removing users from the account. Those actions could be a follow-up after stripping permissions—when it is clear that those identities no longer are needed. Additionally, you could periodically list all users and check their states. Remove users from your account that have an invalid, suspended or (kind of) deleted state.

IBM Cloud has API functions to remove a user from an account, to delete a service ID and its associated API keys and to delete a trusted profile.

Conclusions

Regular account cleanup is part of account administration and security best practices, not just for cloud environments. In our blog post on identifying inactive identities, we looked at the APIs offered by IBM Cloud Identity and Access Management (IAM) and how to utilize them to obtain details on IAM identities and API keys.

In this blog post, we discussed an approach on how to automatically clean up privileges that were granted to now inactive identities. It is important to note that some housekeeping in the form of (audit) logs and a list of exempted identities is needed to keep your apps and workloads running. In that sense, do it, but don’t overdo it.

See these blog posts and service documentation for further information:

• Blog post: Cloud Security: Identify Inactive Identities
• Blog post: IBM Cloud security: How to clean up unused access policies
• Blog post: Data Scraping Made Easy Thanks to IBM Code Engine Jobs
• IBM Cloud Code Engine: Working with the Periodic timer (cron) event producer

If you have feedback, suggestions, or questions about this post, please reach out to me on Twitter (@data_henrik), Mastodon (@data_henrik@mastodon.social) or LinkedIn.