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.
Overview of IBM Cloud APIs for platform services.
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:
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:
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.
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:
Entity Relationship diagram for the database schema.
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.
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:
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:
Report generated on existing IBM Cloud IAM Access Groups.
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:
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.
The source code for the discussed project is available on GitHub.