Permissions, roles, and groups
Beyond establishing how identities are created and authenticated in a cloud environment, identities require some level of permissions to access resources within those cloud environments. In some cases, there may be a default level of access granted based on the type of account created (such as a default administrative user) or the assignment of users to a particular group that has been assigned an access policy (see Figure 3.8 for an example of policies in AWS):
Figure 3.8 – List of available AWS managed policies
For some cloud components and services, the concept of inheritance also exists, as well as the ability to manage permissions through RBAC and ABAC. Administrators may manage users and their permissions within a portal user interface ( UI); however, they may also do this through the CLI, application programming interface (APIs), the use of cloud provider SDKs, or through integrateduser life-cycle and management applications.
When assessing a customer cloud environment, there are several things that an auditor should be familiar with in relation to access. The first is understanding the default high-privileged users and/or roles that exist within an environment and reviewing how that access is managed. Some cloud providers offer the ability for time-bound, temporary, logged access when elevated privileges are required. An example of time-bound access can be seen in Figure 3.9:
Figure 3.9 – AWS time-bound access
In the case of time-bound access, any configuration of time boundaries, workflows, or approval process for the temporary access should be reviewed. The auditor should note that using a workflow process may not be possible for all privileged role and user types and should determine through customer interviews whether there are alternative processes for controlling high-privileged access.
Another thing auditors should note is that for some cloud services, designating a user with a specific title within the cloud such as Owner or Contributor may effectively be the same as granting permissions or access rights. Additionally, such as in AWS, a user may be able to “assume” the permissions of another user or role, which could potentially elevate the permissions for the user, depending on the policy and existing permissions for that user. The concept of inheritance and delegation, such as in GCP, may also come into play. In Figure 3.10, you can see an example where policies have inheritance defined. Here, the user may not be granted access rights explicitly but due to inheritance may gain additional rights to a resource:
Figure 3.10 – Example GCP organization policies with inheritance
Other areas an auditor will want to review will include the use of individual user identities to run services and which permissions have been granted, the assignment of privileges to service and workload identities (and whether they may be over-privileged), and the use of custom roles or roles that have been cloned from the cloud provider’s default roles. The definition of default (or built- in) roles can be found in cloud provider documentation. For custom or customer-defined roles, an auditor may need to request a more detailed listing of which permissions are included. As in Figure 3.11, a cloud provider will distinguish between which roles are provided as default roles. A cloud provider may offer hundreds or thousands of roles and permissions for use within the cloud customer environment. Here is a sample list of default privileged roles you should be aware of:
Figure 3.11 – Example Azure built-in and custom roles
Now that we’ve discussed attributes in defining access for users in cloud environments, let’s take a deeper look at privileged permissions. As mentioned at the beginning of this chapter, it’s important that auditors know and can identify highly privileged roles in cloud environments to properly assess governance and risk.
