GCP Security: 3 Ways to Reduce Risks

GCP Security

Many developers prefer Google Cloud Platform (GCP) because it is easy to use and has a positive, seamless user experience. Overall, it has more engineering finesse than AWS and Azure.

These are hugely valuable features to DevOps teams – after all, they support speed and collaboration, which is a big deal if you’re trying to hit KPIs and always deliver more software, faster.

Developers Love GCP

There aren’t a bunch of hoops to jump through to complete tasks, and obtaining the permissions you need is a quick and simple process: In GCP, a developer typically uses a master account to manage projects. All you have to do is log in with your Google account and set the permissions to any project and you’re off to the races. No cumbersome security tools or processes to follow that will slow you down.

Speed and collaboration matter. Organizations move to GCP and other cloud platforms specifically to accelerate business objectives and scale. So it’s no surprise that DevOps want an environment that supports their priorities.

But what happens when the very thing that facilitates growth becomes a liability? What happens when a collaborative environment leads to identity sprawl and security vulnerabilities?

Security Looms Large

The answer is obvious – attackers target your pipeline. Look at it this way: companies have dozens, hundreds, and sometimes even thousands of human and synthetic users requiring access to complete tasks. We know that GCP strives to make the process of granting access easy. What tends to happen, though, is too many accounts end up with over-privileged access that remains open. Most cloud solutions with an identity engine attempt to keep things simple for the administrators and users––but this leads to over-provisioned access.

As we know, over-provisioned access and/or elevated standing privileges represent a significant threat to an organization’s security.

Attack surfaces grow exponentially when standing privileges are the norm. Even if access is dependent on identity authorization, or a task has time limitations, when access remains open 24/7, users are subject to external attacks.

The challenge, then, is to equip an organization with an identity and access management solution that supports best security practices but does not impede developers or software development lifecycles (SDLC).

Without question, Britive is first and foremost a security platform. But our broader mission is to support an organization’s business objectives in the cloud. That’s why we built our Dynamic Permissioning Platform – to meet the security and performance needs of DevOps, security, and cloud infrastructure teams. Our goal is to facilitate a migration to unified DevSecOps processes.

GCP Security Best Practices

Enforcing best security practices in GCP requires the harmonization of three key concepts:

1. Temporary access or JIT permissions
2. Secrets governance
3. Zero standing privileges

Knowing that DevOps is tasked with delivering applications frequently and rapidly to support business growth, it makes sense that, absent a solution that aligns with security policies and workflows, administrators have few options but to over-provision privileges.

Let’s take a look at best security practices for GCP, and why Britive is the platform to finally bridge the gap between security and business in the cloud.

⇒ Deploy Ephemeral Just-in-Time (JIT) Privileging

Where a GCP user previously had standing access privileges that (potentially) extended around the clock indefinitely, implementing JIT grants reduces your attack surface by granting privileges to users on-demand according to their role. True JIT means ephemeral access rights that expire automatically, e.g., after a predefined time period, at the close of a timed coding session, or when an employee leaves the organization. This ensures that organizations minimize attack surfaces constantly and move toward a Least Privilege Access (LPA) model.

⇒ Enforce Secrets Governance

JIT  privilege grants means human and synthetic IDs can quickly check out a role-based, elevated privilege profile for a specific cloud service, either for the duration of a session or task, for a set amount of time, or until the user checks the profile back in manually. Once the task is complete, privileges are automatically revoked.

Unfortunately, users often have hard-coded privilege credentials to access sensitive resources. Granted, hard coded secrets ensure builders have the access they need when they need it, but they present an unnecessary security vulnerability that is difficult to correct. Organizations should consider elevating secrets management with a cloud-native, holistic management platform that provides visibility and access for human and non-human identities across the GCP environment.

⇒ Eliminate Standing Privileges

The ability to dynamically add and remove privileges lets your DevSecOps team maintain a Zero Standing Privilege (ZSP) security posture. It works on the concept of Zero Trust, which means that by default no one and nothing are trusted with standing access to your GCP account and data.

In a ZSP model, human and non-human users gain access to restricted resources the moment they need them, only for as long as they need them. Such JIT permissioning methodology results in the least number of open privileges at any given moment in time.

Privilege right-sizing is an important component as well. Here, privileges are only given when needed, and only for a limited time, but users’ minimum viable privileges are provided, to reduce the attack surface for hackers. You don’t need a bunch of keys to open a door when one key will do the job.

Conclusion

In GCP, shifting to JIT permissioning can pay dividends.

On the whole, it's recommended to adhere to the principle of zero trust. This means a do-not-trust but verify posture at the identity/privilege control point. Unfortunately, merely enforcing LPA as many traditional IAM, PAM and CIEM solutions do, which is necessary to minimize your privilege attack surface, is insufficient to maintain zero trust access. If there’s a misconfiguration, or an identity is compromised, the bad actor responsible can still access your environment and cause damage – especially if the compromised user has elevated permanent access or an errantly over-privileged account.

Britive’s platform for managing access permissions – for humans and nonhumans – significantly increases GCP velocity while closing security gaps to meet your organization’s DevSecOps needs.