Assessing access assignment controls
Beyond establishing who can access an environment and what they can do, another important area to assess is who can configure or modify access assignments for identities. In some environments, the assignment of access may be a completely automated procedure through account life cycle workflows. However, even with this automation, it’s important to establish who can modify it and influence the access being granted. It’s also important to clarify whether there are any exception processes in place that could potentially bypass that automation.
In this walk-through, we will assess which identities can perform user and access administration. For our control, we will look at testing Azure and GCP cloud environments to validate that all user access is provisioned through the organization’s entitlement life cycle process. For our example control, we need to verify that there is no evidence of access being manually assigned.
Microsoft Azure
To validate the control that access for the cloud environment is only assigned through an enterprise lifecycle tool, we will execute the following test steps to verify which accounts have provisioned access within our desired testing time frame:
- Navigate and log in to the Microsoft Azure portal.
- Navigate to Azure Active Directory.
- Navigate to the Roles and administrators blade.
- Select the Audit logs blade.
As shown in Figure 8.7 , when accessing Audit logs from this navigational path, the results are automatically filtered on the RoleManagement category. You can do additional filtering as needed to get events for the desired date range and even filter on a more granular set of activities:
Figure 8.7 – Microsoft Azure role management audit logs
Within the list of audit log results, you can select each entry to get more details about the activity and what may have been modified. It’s important to note that in some cases, your report results will include default system maintenance activities, such as in Figure 8.8. These can be distinguished based on the Initiated by (actor) details:
Figure 8.8 – Microsoft Azure audit log entry performed by a default service
Now that we’ve determined a method for testing access assignment controls within Microsoft Azure, let’s look at testing this control in GCP.
GCP
Within the GCP environment, Google has provided resources that allow for the dynamic querying of policies and policy settings. As shown in Figure 8.9, you can develop your own custom query from scratch or use another query template to get started:
Figure 8.9 – GCP Policy Analyzer custom query
To effectively leverage this querying ability, you will need to understand the roles, permissions, and/ or properties you want to assess. As shown in Figure 8.10, the query builder allows you to filter and select based on different options. In Chapter 3, Identity and Access Management Controls, we covered the resources available to help familiarize yourself with the roles and permissions within GCP.
Figure 8.10 – GCP Policy Analyzer custom query filter
After creating a query with a list of the permissions and/or roles that you want to validate, as shown in Figure 8.11, you will get some additional options to query based on options related to inheritance. Remember that inheritance is one of the constructs that GCP uses and that you will need to be aware of it as you perform control testing assessments. Once you have a list of users with permission to perform access assignments, you can then query activity logs to determine whether that access has been used:
Figure 8.11 – GCP Policy Analyzer custom query and inheritance options
Now that we’ve covered some ways to assess a basic control related to understanding who can perform access and assignments and when that ability may have been used outside of the control process, let’s look at performing an assessment of privileged access controls in AWS and Azure.