Cloud IAM: Identity and Access Management

A crucial part of cloud security involves managing user identities, their permissions, and the resources they have access to. Organizations may have users accessing public cloud resources from a number of different devices and networks. And this can be an extremely challenging task. Additionally, organizations may be utilizing multiple clouds and managing access across all of those public clouds. Most public cloud vendors today offer Cloud Identity and Access Management (Cloud IAM) frameworks. These frameworks are designed to facilitate and secure users’ identities and their access to resources.

Cloud IAM provides fine-grained access control and visibility for centrally managing cloud resources. Now, let’s delve deeper into cloud identity and access management, specifically within the context of Google Cloud Platform and G Suite. We will explore how organizations can effectively utilize the cloud IAM framework to secure resources and provide access to users.

What is Cloud IAM?

Cloud IAM (Cloud Identity and Access Management) holds significant importance in an organization’s overall security strategy. It serves as a key component specifically for securing resources within the public cloud environment.

Cloud IAM helps organizations manage access control by helping to define “who” has “what” access for “which” resource. The who are members, the what are the role and the resources are anything we want to grant permissions on in the public cloud.

One of the key aspects of security when it comes to user access to resources is establishing mechanisms to verify their identities. Whether users access public cloud resources from on-premise hardware or from a mobile device – this verification is essential.

Let’s take a look at the following aspects of cloud Identity and Access Management and how each is able to bolster an organization’s public cloud security:

• Identity and Access control
• Cloud Permissions and Roles
• Policy-Based Access
• The intuitive, single management interface
• Auditing
• Automation

Google – Cloud Identity and Access Management

When managing Identity and Access control on public cloud resources, it’s important to follow the principle of “least privilege.” This principle aligns well with most organizations’ security policies. In other words, our goal is to restrict user privileges to the minimum necessary to access resources. This applies whether the resources are located on-premise or in the cloud.

Best Practices for cloud IAM access assignment include:

• Use Predefined roles over Primitive roles (differences explained below)
• Treat each part of an application controlled by cloud IAM as a separate trust boundary
• Grant roles at the smallest scope needed
• Restrict the number and specifics of who can operate as a service account
• Restrict who can create service accounts
• Be restrictive on granting owner roles to members. This allows the modifying and managing of the IAM policy for that resource

When thinking about G Suite Cloud Identity and Access Control, we first establish the identity of a user, group, or domain. Afterward, we apply Google Cloud permissions to provide access control. Identity in the context of Google Cloud Platform (Google’s nomenclature is members) can be one of the following:

• Google account
• Service account
• Google group
• G Suite domain
• Cloud Identity domain

Google Cloud Permissions and Roles

In today’s RESTful API-driven world, public cloud vendors are heavily using RESTful APIs. These APIs allow customers to interact with their public cloud resources. This holds true as well with defining permissions in the public cloud, using IAM. Permissions define which operations are allowed on a given resource in the public cloud. As is the case with Google, these permissions are represented in the form of the following:

• <service>.<resource>.<verb>
• pubsub.subscriptions.consume as an example

The interaction with public cloud resources is heavily driven by RESTful APIs. Frequently, the available permissions align themselves with the exposed RESTful API methods. So, generally, there is a 1:1 correlation with permissions to API call that is exposed.

Roles are collections of permissions that are directly assigned to a specific user. In fact, with Google Cloud Platform, you cannot directly assign permissions to a user, but rather assign roles to a user. Roles make assigning permissions very efficient in that a user assumes all the permissions that are defined in that role. So, you can create role-based access permissions that define which permissions a typical user in that role would assume.

As an example, Google Cloud Platform has three types of roles that can be assigned via cloud IAM:

Primitive roles

Role Name	Role Title	Permissions
roles/viewer	Viewer	Permissions for read-only actions – the state is preserved
roles/editor	Editor	Includes Viewer permissions and permissions to modify the state
roles/owner	Owner	Includes all Editor permissions and includes managing access control, billing

Predefined roles – The predefined roles that Google Cloud Platform offers are more granular than the legacy primitive roles. They allow for more fine-grained control over access. So, while an might be able to publish and have access to more actions, a predefined publisher role may only be allowed to publish.

Custom roles – The custom roles are where we can truly get creative when it comes to the exact permissions we want to include in a role. When organizations want extremely granular and customized roles that truly align as closely as possible to the role-based access they want to assign to member objects, customized roles can accomplish this. With customized roles, we would get into being able to uncover the low-level RESTful API-based control mentioned earlier.

Policy-Based Cloud Access

Adding to the building blocks of cloud Identity and Access Management includes defining IAM Policy. What is Policy as it relates to Google public cloud IAM? IAM Policy defines which objects (members) are assigned to which role. Users could be granted their role based on matched criteria presented in a policy.

With cloud IAM policies, they are organized hierarchically with the organization node being the top-level entity. Policy flows from top to bottom with child resources inheriting the policies assigned on the parent entity. This does not flow the other way around with child policy affecting parent entities, etc.

Policies can be managed via API in the Google Cloud Platform using IAM methods which allow:

• Setting policies – setIamPolicy()
• Getting policies – getIamPolicy()
• Testing permissions for a resource – testIamPermissions()

Of course, RESTful API interaction with policies is much preferred for automating policy as well as interacting and making, or getting, bulk changes from the policy API.

Intuitive Single Management Interface

Google Cloud Platform Identity and Access Management provides organizations with a single management plan for managing users, roles, resources, policies, API endpoints, etc. All Cloud IAM tasks can be easily performed from this unified platform. This provides a “pane of glass” approach to configuring members, building roles with the appropriate permissions, and using policy to define role allocation among members, along with other cloud-driven IAM tasks.

IAM Auditing

Auditing is a staple when it comes to securing systems either on-premise or in the cloud. It helps to give visibility and accountability to G Suite administrators and other users for any actions they may perform in business-critical systems.  Similarly, auditing, as it relates to cloud IAM, allows organizations to determine who did what, wherein the system, and when it was done.

With Google Cloud Platform IAM auditing, there are two audit logs for each project and organization – Admin Activity and Data Access. The admin audit logs entries for API calls that includes modifying any configuration of resources and other tasks that administrators might perform.

Viewing logs for admin logging requires the IAM roles of Logging/Logs Viewer or Project/Viewer. Data Access logs record API calls relating to any user-provided data. Viewing the Data Access logs requires the Logging/Private Logs Viewer or Project/Owner IAM roles.

Thoughts

Cloud IAM (Cloud Identity and Access Management) is a crucial part of any organization’s security strategy to make sure both identity and access are validated so that access to business-critical resources in the public cloud has the correct permissions applied. Among the many powerful features of cloud-based IAM are Identity and Access control, Permissions and roles, Policy-Based Access, single management interface, and Auditing capabilities. By using these and other security features of cloud-based IAM in conjunction with other cloud security measures such as API-based CASB, organizations, and GDPR compliance are able to drastically bolster the security of public cloud resources. Making sure the identity of users accessing cloud resources is validated and making sure those validated users have fine-grained permissions applied helps to ensure the best practice of “least privilege” access.

Try SpinOne for free

Check out SpinOne API CASB security expertise and keep your clod data protected!