Most businesses today are leveraging cloud services for critical business applications. However, as companies continue to adopt the cloud, it’s crucial to understand the security requirements for safeguarding sensitive business information.

Since security threats continue to advance, preventing leaks and data theft is an important consideration for organizations. Thus, businesses need to take active steps to improve cloud security.

What is Identity and Access Management (IAM)?

Cloud security is a set of policies, procedures, and technologies designed to address external and internal threats to business security. One such framework is Identity and Access Management (IAM) security, a cybersecurity best practice that ensures greater control of user access.

Human error is perhaps the weakest link in any cybersecurity system, and every organization needs a way to manage identities and control access. IAM security enables organizations to manage digital identities by identifying, authenticating, and authorizing users and thus reducing identity-related access risks within a business.

This article covers the pitfalls of cybersecurity systems and identifies the best practices for establishing IAM security via the Google Cloud Platform (GCP).

Why IAM?

Before discussing cloud identity and access management, it is essential to notice the pitfalls of a cybersecurity system. The first step is to assess and manage permissions on Service Accounts – an account for an application or compute workload instead of an individual end user, according to GCP documentation.

Your workload security is a function of who has access to your data and what access privileges they hold. Thus, excessive permissions granted to unmanaged service accounts account for most security breaches.

As an example, let’s look at the Google Cloud Compute Service. The Compute Engine creates a default service account with the IAM project Editor role. This Editor role contains all privileged permissions to create and delete resources for most Google Cloud services. Although you can modify the service account’s roles to limit access to it securely, if one were to create a new instance, the default service account would be automatically added to the instance. Thus, as one keeps creating new instances, the default service account with the editor’s role would be able to access all GCP services or applications. In such a scenario, if the privileged service account were to be breached, the intruder could access any instance or application that runs using the Compute Engine default service account.

To avoid such a circumstance, IAM security manages access within an organization by assigning users specific roles and ensuring that they have the right access privileges required for their job. Moreover, businesses should follow certain IAM security best practices to prevent any data breaches.

Best Practices with IAM security

IAM security has become an essential element of the security framework. Whether you’re using the GCP IAM or other services, it’s critical to ensure that the identity and access management tools and processes are properly set up.

The Principle of Least Privilege

One of the most common roles and permissions best practices is applying the principle of least privilege. IAM least privilege refers to an information security concept in which users are given the minimum levels of access or permissions without interfering with users’ daily workflows. This practice is fundamental in protecting privileged access to high-value data and assets.

Image Source

While organizations can implement role-based access control, they can also leverage attribute-based access control to define the permissions necessary across different departments further. However, the end goal is regularly auditing usage and reducing unnecessary permissions. The principle of least privilege is also vital to limit administrative access so that single admins don’t have excessive permissions.

Moreover, by limiting super-user and administrator privileges, the least privilege enforcement helps to reduce the overall cyber attack surface.

However, as a service scales - so does the number of IAM roles and inter-related privileges. Presenting Policy Intelligence which is a revolutionary AI and ML enforcer that leverages data to optimize IAM policies.

Policy Intelligence is like a policy traffic policeman that seamlessly:

- Rolls out policy changes

- Maintains information on who has access to what

- Simulates policy changes to ensure the right stakeholders have relevant access

Image Source

Reviewing and Removing Excess Permissions on Existing Service Accounts

As we’ve mentioned, IAM security ensures that users have the right access privileges. Without this, everyday operations like bulk approvals for access requests and the lack of access review processes would lead to excessive access privileges.

Under the GCP IAM system, one doesn’t directly grant permissions. Instead, organizations grant roles that contain one or more permissions. These IAM roles are divided into: basic roles, predefined roles, and custom roles.

The GCP documentation warns users against using basic roles unless there is no alternative, as basic roles include thousands of permissions across all Google Cloud services. If such an unmanaged service account were to remain neglected, it would be vulnerable to compromise and exploitation. Thus, the solution is to go with Predefined or Custom roles. While predefined roles are created and maintained by Google, Custom roles are user-defined and allow you to bundle one or more supported permissions to meet your specific needs.

Image Source

We advise that organizations follow the practice of creating a dedicated custom service account for each instance and use another custom service account for each application, and grant required access. Although this may seem complicated to manage, it will be advantageous in the long run. Moreover, GCP’s IAM recommender alerts you to the permissions that are not used by the service account, and you can remove/modify them accordingly.

Introducing Google’s Policy Troubleshooter that helps you investigate access issues. For instance, if a user has permission to an asset but is unable to call an API, the Policy Troubleshooter will quickly pinpoint why a user doesn’t own a particular access.

To access the Policy Troubleshooter on your GCP console, head over to IAM & Admin > Policy Troubleshooter

Now, the tool prompts you to fill in three key parameters:

For more info on resource name nomenclature, check out the official documentation.

Once you have filled the form, click on Check Access.

With reference to the annotations on the screenshot:

1. 1. The top portion validates the evaluation info of the principal user.

2. 2. The IAM allow policy details shows the access granted

3. 3. Finally, role bindings reveal roles that contain the relevant permissions

   a. Click on Role binding details to view more details

The result is a holistic and comprehensive background check on any user’s access privileges - thus helping system admins to easily analyze why access issues arise.

The Service Account Key

Unlike normal users, service accounts do not have passwords. Instead, service accounts use RSA key pairs for authentication: Since the private key allows you to authenticate as the service account, having access to the private key is similar to knowing a user’s password. This private key is called the service account key. The key-pairs used by service accounts are divided into two categories: System-managed and User-managed.

System-managed key-pairs are automatically rotated by Google and are used for signing for a maximum of two weeks. On the other hand, User-managed key-pairs can be created and deleted by users. Users are responsible for rotating these keys periodically to ensure the security of their service accounts.

Image Source

However, service account keys can become a security risk if not managed carefully. Credential leakage, privilege escalation, and non-repudiation are some of the main threats related to service account keys. As mentioned in the google cloud documentation on service account keys, you can follow certain practices to avoid these threats:

• Use alternatives to creating service account keys.

• Use organization policy constraints to limit which projects can create service account keys.

• Don’t leave service account keys in temporary locations.

• Don’t pass service account keys between users.

• Don’t submit service account keys to source code repositories.

• Don’t embed service account keys in program binaries.

• Use insights and metrics to identify unused service account keys.

• Rotate service account keys to reduce security risk caused by leaked keys.

• Use uploaded keys to let keys expire automatically.

Workload Identity

Some applications running on GKE (Google Kubernetes Engine) might need access to Google Cloud APIs. Workload Identity allows a Kubernetes service account in your GKE cluster – outside Google Cloud – to impersonate a service account by using credentials from an external identity provider.

The process of configuring Workload Identity works by using an IAM policy which binds the Kubernetes service account member name to an IAM service account (having the permissions your workloads need). Since Google manages the namespace service account credentials, the risk of accidental disclosure of credentials is much lower than service account keys.

Moreover, the credentials actually issued to the Workload Identity are only valid for a short time, thus, reducing the blast radius in the event of a malware attack

DevOps and Least Privilege Policies

To develop cloud services, development and operations teams often come together and are known as DevOps. This process can also be implemented via the Google Cloud Platform and is facilitated by companies like D3V tech.

However, organizations must be careful about incorporating security into the continuous delivery and deployment of Cloud infrastructures, cloud platforms, and cloud applications. For secure deployment and engineering, separation of duties is essential. It ensures that even the DevOps team only has the access required to perform their jobs in accordance with the principle of least privilege.

As a result, you can efficiently manage the security functions and properties in the delivered code to evade vulnerabilities from both internal and external threats.

Google Cloud Platform also offers whitepaper guides and a checklist for security policies and best practices on Google Cloud to assist both small and large in maintaining their IAM security.

Cloud Security Solutions by D3V

The D3V team offers advanced and robust security solutions to our clients as we help them overcome challenges and adapt to a new networking infrastructure with Google Cloud migration.

In the past, we have assisted a Multi-Billion Dollar Supermarket Chain to overcome scalability issues and security vulnerabilities like their promotions attracting malicious traffic that threatened the server’s stability and security.

The threat to Cloud Security is constant - so sign up for a free consultation to initiate the process of setting up the Google Cloud IAM and other cloud security permissions.