When was the last time you looked over existing access policies in your cloud account? It’s very likely that it is not on your regular tasks (yet), but it should be done regularly to improve security.
In IBM Cloud, access policies define who receives which set of privileges granted on what resource. When a policy is evaluated and then applied to allow access, “last-permit” data is updated. You can utilize that data to identify unused or inactive access policies.
In this blog post, we provide an overview of existing IBM Cloud access policy types. Then, we show you how to retrieve information on inactive access policies and discuss how to act on that data. This will demonstrate how to clean up unused policies to enhance security for your IBM Cloud environment:
Details of an access policy of an IBM Cloud IAM access group.
Overview: Access policies
In IBM Cloud Identity and Access Management (IAM), access policies specify what access is granted to whom for which resources. In general, there exist two types of policies, access and authorization:
The authorization type is used to grant a service access to another service. An example policy could be to allow a storage or database service (instance) to read an encryption key from IBM Key Protect for IBM Cloud.
The access type helps determine resource access for either all the identities as members of an access group or for individual IAM identities (e.g., a user, service ID or trusted profile). A typical policy would grant an access group reader and writer role for a specific storage bucket of an IBM Cloud Object Storage instance. Another example would be to grant an individual user the administrator privilege for user management in the account.
Policies can be scoped very narrowly—this means that only selective privileges on a specific resource are granted. More generic policies grant access to all instances of the same service type or to all resources in a resource group or region. Policies could even include time-based restrictions. I discussed them in my recent blog post, “For a short time only: Time-based restrictions for enhanced cloud security.”
The screenshot above shows the IBM Cloud console when editing the details of an access policy for an access group. It grants Viewer and Reader privileges on all identity- and access-enabled services in that resource group “cloudsec-workshop.” Moreover, access is restricted to the shown time range. A JSON representation for the access policy is available in the console. The screenshot below shows the partial JSON object for the discussed sample policy:
Partial JSON object for an IBM Cloud IAM access policy.
Identify unused access policies
As described, access policies define the privileges on resources for the members of an access group, for individual IAM identities or for services. When resource access is requested, the policies are evaluated and either no access is granted or a policy is found that permits access. In IBM Cloud, that usage of an access policy is recorded with both the timestamp as last_permit_at and a counter last_permit_frequency.
You can use that information to audit access policies and identify inactive policies. The IBM Cloud console lists policies that have been inactive for 30 days and longer. It does not show entirely unused policies.
An alternative to the IBM Cloud console is the IAM Policy Management API. It allows you to retrieve all policies and include the “last-permit” attributes into the result sets when setting the format parameter to include_last_permit. We built a small Python tool to simplify interaction with that API and support some filtering and data output as JSON or CSV data. The tool is available in the GitHub repository ibmcloud-iam-keys-identities. See the README file for how to retrieve the policy data.
The following shows tool output in JSON format for an infrequently used and inactive access policy. It belongs to an IAM access group (subject) and grants Viewer permissions on a specific resource group in an IBM Cloud account:
Inactive IAM access policy for an access group.
Manage inactive policies
Once you have the list of policies, the question is how to manage them. In general, you should check on their type (access or authorization) and the type and role of privilege granted. Is the privilege on a specific service instance or very broad (e.g., on a resource group or all instances of a service)? Is it a role granting minimal access or broad, like Manager or Administrator?
Following the principle of least privilege, it might be time to adjust and cut down on granted privileges. It is also a good time to check if all policies have a great description. Descriptions are optional but should be used as a best practice to ease administration and improve security. Be aware of service-to-service authorizations that grant cross-account access for resource sharing and policies involving trusted profiles:
Recently used policies: You probably want to keep them because these policies should have been created for a reason and they are in use. However, you might want to check if they were defined with too broad privileges.
Policies inactive for 30 days and longer: You should investigate for what the policies are in place for. Maybe they are used for infrequent tasks? If not done already, you might want to consider restricting the policies with time-based restrictions. Thus, they can only be used during the assigned time window. Something to also check is whether the policy is restricted to past dates.
Policies that have never been used: These need to be investigated. Who created them and for what purpose? Why were they never used? There could be good and bad reasons.
To improve security, you should delete those policies that no longer are needed. Depending on how you analysed details for a policy—in the IBM Cloud console, or with the CLI or API—you want to continue in the same environment and delete obsolete policies. Although you can retrieve all policies with a single API call or list the inactive ones in a single list in the console, removal depends on the policy type and the subject. Each has its own command in the console and CLI.
Conclusions
Access policies define who receives which set of privileges granted on what resource. They exist in different flavors for access groups, IAM identities and service-to-service authorizations. If access policies become stale and are no longer needed, they pose a security risk and should be removed. The goal is to operate with the least set of privileges.
IBM Cloud offers functionality to identify inactive or unused access policies. We discussed how such policies can be identified and how to handle them. So, when was the last time you analysed your IBM Cloud account for inactive identities?
Get started with the following resources:
If you have feedback, suggestions, or questions about this post, please reach out to me on Twitter (@data_henrik), Mastodon (@[email protected]) or LinkedIn.
Technical Offering Manager / Developer Advocate
