Logo Spinbackup.com

Essentials for Cloud Access and Security Management Success

Essentials for Cloud Access and Security Management Success

Cloud Access and Security Management
A crucial part of cloud security involves managing user identities, their permissions, and resources they have access to.  This can be an extremely challenging task for organizations who 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 (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 how organizations can make use of the cloud IAM framework as a means to secure and provide access to resources for their users.

Cloud Identity and Access Management

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 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
  • Permissions and roles
  • Policy Based Access
  • Intuitive, single management interface
  • Auditing
  • Automation

Identity and Access Control

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

Google Cloud Identity
When thinking about Identity and Access Control, we first establish the identity of a user, group, or domain, and then apply 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

Service Account management – allows creating an identity such as code

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:

  • <service>.<resource>.<verb>
  • 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.

Rolesare 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

    – 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 – state is preserved
roles/editor Editor Includes Viewer permissions and permissions to modify 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.

Predefined roles

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 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 plane 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.

IAM & admin settings

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 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, where in 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.

Google’s Stackdriver Logging

Thoughts

Cloud Identity and Access Management (IAM) 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 have 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 CASBs, organizations are able to drastically bolster 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.

3,298 total views, 17 views today

Related Post