IBM Cloud offers APIs to retrieve identity and access management data. In this post, we show how to analyze this data to improve your cloud security setup.

With an IBM Cloud account comes responsibility, including setting up and monitoring access management for your cloud resources. In the past, I have shared with you how to get insights into IBM Cloud account privileges or how to improve security by identifying inactive identities. In this blog post, we will give you an overview of existing APIs you can use to obtain identity and access management (IAM) and resource data. Then, we will show you how to analyze that security data. With these insights, you can improve security for your IBM Cloud account and its resources.

There are many ways to analyze access management data. We chose to retrieve the data and store it in a relational database. That way, we can easily combine data from multiple sources and run SQL queries, thereby generating security reports.

The source code for the discussed project is available on GitHub.

Overview: Access management data

If you have worked with IBM Cloud and looked into security and compliance before, you may have already used all the following sources to improve account security:

• Activity data logged to Activity Tracker.
• Runtime logs found in Log Analysis.
• Security posture analysis performed by the Security and Compliance Center.
• IAM reports on inactive identities and inactive policies.

In addition to the above, there is data about the account, its resources, user and service IDs, and their privileges. In this post, we refer to that data as “access management data.” It can be viewed and retrieved in many ways, including through the IBM Cloud console (UI), the command line interface (CLI) and other interfaces. In the following, we focus on the Application Programming Interfaces (APIs) for the IBM Cloud platform services (see screenshot above). You can access their documentation by going to the API and SDK reference library and then selecting the Platform category.

For access management data, the important IBM Cloud APIs include the following:

• User Management to retrieve a list of users in the cloud account to analyze
• IAM Identity Services to look into service IDs, trusted profiles and API keys
• IAM Access Groups for details on access groups and their members
• IAM Policy Management to analyze access policies of access groups, service-to-service authorizations and access roles
• Resource Manager for details on resource groups (which are often referenced in access policies)
• Resource Controller to retrieve information about service instances

There are more APIs available, but the above form the core. Data from these APIs helps establish a (mostly static) snapshot view of the security setup. It is similar to what (on a high level and ignoring details) the IBM Cloud Security and Compliance Center evaluates.

Each of the API functions requires an IAM access token and returns a set of JSON data. The real value comes from combining the data for the full picture—composing the puzzle from many pieces. It is the first step toward the security analysis. The data from all the APIs can be held shortly in memory (just for running some reports) or it can be persisted for deeper analysis. We opted for the latter and decomposed the JSON objects into relational tables. This means we can run SQL queries and benefit from its expressional power for the analysis.

It is important to note that the analysis does not cover any dynamic membership rules or context- or time-based access decisions. Deciding on access as part of IAM processing requires more dynamic data. We don’t want to and cannot mimic IAM decision. The analysis only helps to find interesting spots in the security setup to investigate and possibly to improve.

Retrieve and store

To build our base with access management data, we started by mapping the different JSON objects to relational tables. Some of the JSON objects have nested data. For example, when listing policies, the results include the policy metadata and policy subjects, roles and resource information. This leads to four policy-related tables in our data store. Similar mappings need to be performed for the other API results. It resulted in a database schema as depicted below:

We decided to use Python to retrieve and store the data based on existing code from previous work. Depending on the API function, data retrieval could require paging through result sets. Often, the number of objects in a single result is limited to 100. Some API functions require additional parameters to be passed for enriched results. The latter contain additional details that are useful for security analysis.

We use SQLAlchemy—a database toolkit for Python—for access to the data store. It allows you to easily switch from, for example, SQLite to PostgreSQL or Db2 on Cloud as a backend database.

Analyze cloud access management

With the data store in place, it is time to analyze the cloud access management data. By combining data that is usually only available in different console pages or from multiple API calls/CLI commands, we can easily answer security-related questions like these:

• Which cloud service instances are referenced in access policies but do not exist?
• Which cloud service instances exist but are not used in any access group and their policies?
• Which users (or service IDs or trusted profiles) are not a member of any access group?
• Which access groups do not have any policies with Reader or Viewer roles?
• Which access groups do not reference any region or resource group in their policies?

The SQL queries for the above questions can be run from a Python script in a Jupyter or Zeppelin notebook or other SQL clients. The screenshot below shows part of a simple text-based report produced by a simple Python script. The related SQL statement joins many of the tables in our data store:

Conclusions

The analysis of cloud access management data can enhance the security of your IBM Cloud account. It adds to the existing platform-provided tools that I mentioned in the overview. The generated reports serve as input to revisit existing access groups and may lead to the removal of some policies and access groups. As noted, it is a static analysis and does not consider context data and dynamic rules.

The tool and its code is available in a GitHub repository. If you have an interesting query to share or improvements to add, please feel free to open a pull request. Also, check out some of our other security blog posts:

• Enhance Cloud Security by Applying Context-Based Restrictions
• Cloud Security: Identify Inactive Identities

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.