A crucial part of cloud security involves managing user identities, their permissions, and the resources they have access to. This can be an extremely challenging task for organizations that may have users accessing public cloud resources from a number of different devices and networks. Additionally, organizations may be utilizing multiple clouds and managing access across all of those public clouds. Most public cloud vendors today provide Cloud Identity and Access Management (Cloud IAM) frameworks to help facilitate and secure users’ identities and access to resources.
Cloud IAM provides fine-grained access control and visibility for centrally managing cloud resources. Let’s take a closer look at cloud identity and access management in the context of Google Cloud Platform and G Suite, and how organizations can make use of the cloud IAM framework as a means to secure and provide access to resources for their users.
Enhanse your cloud identity and access management with CASBTry SpinOne
Table of Contents
What is Cloud IAM?
Cloud IAM (Cloud Identity and Access Management) is a key part of an organization’s overall cyber security strategy when it comes to securing resources in the public cloud. 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 a user accessing resources is having mechanisms in place that prove that users are who they say they are whether they are accessing public cloud resources from on-premise hardware and networks, or from a mobile device connected to the Internet. 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
Google Cloud Identity and Access Management
In thinking about Identity and Access control on public cloud resources, the idea of “least privilege” aligns itself very well to most organizations’ security policy. In other words, we don’t want a user to have any privilege they don’t absolutely need to access resources, both 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 role to members as 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, and then 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 Cloud Permissions and Roles
In today’s RESTful API-driven world, public cloud vendors are heavily using RESTful APIs to 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:
- pubsub.subscriptions.consume as an example
Since the interaction with public cloud resources is very heavily RESTful API driven, often the available permissions align themselves with the RESTful API methods that are exposed. 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:
- – The primitive role is much of what you would expect from standard-issue permissions found in many different types of systems. These are standard roles that should be familiar to most organizations – Owner, Editor, Viewer
|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
With Google Cloud Platform Identity and Access Management, organizations get a single management plan to be able to manage users, roles, resources, policies, API endpoints, etc. Cloud IAM tasks are easily performed from the same management plane, allowing a single “pane of glass” approach to configuring members, building roles with the appropriate permissions, using policy to define which members get which roles, and other cloud-driven IAM tasks.
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.
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.
Check out SpinOne API CASB security expertise and keep your clod data protected!