Practicing The Principle of Least Privilege in Google Cloud
Access management is a fundamental requirement in achieving security, especially with cloud infrastructure. Think of it this way: You wouldn’t give every employee a master key to your office building that allows them access to every door, so why would you grant employees access to each ‘room’ in the cloud? That’s where the principle of least privilege, or “POLP,” comes into play in your Google Cloud (GCP) environment.
What Is Least Privilege?
The Principle of Least Privilege, also known as POLP, is a fundamental security concept. When dealing with public cloud security, the Principle of Least Privilege concept implies that all identities—both people and non-people—should be granted the bare minimum access necessary to perform their respective duties.
In addition to granting a minimum level of access, the POLP states that identities should only be granted access for the minimum amount of time needed to perform their duties. This concept of limiting access to the minimum time required is frequently forgotten. But this isn’t the only challenge organizations face when applying POLP to the public cloud.
For instance, a user who needs access to a customer information database for an annual report should not have that access throughout the year. Instead, the access should be revoked as soon as they complete their data compiling.
In its simplest form, POLP is assigning permissions or “privileges” to people and non-people identities when needed and removing access when they’re no longer necessary. With that said, while it’s simple to understand in theory, it takes a great deal of planning and commitment to get it right in practice, especially when dealing with cloud infrastructure at scale. In this blog post, we will outline how we helped design security controls for Google Cloud (GCP) environment.
Identifying the 4 Major Identity Risks in GCP
There are four main identity risks that determine the necessity of least privilege. These include the separation of duty, dormant identities, privilege escalation, and toxic combinations.
Separation of Duty
Separation of duties (SoD) is an internal control concept commonly applied which involves the sharing of a set of responsibilities and privileges among multiple users with the intention of preventing fraud and error.
Separation of Duties has two areas. The first is the prevention of conflict of interest (real or apparent), wrongful acts, fraud, abuse, and errors. The second is the detection of control failures that include security breaches, information theft, and circumvention of security controls. It is designed to ensure that identities (people and non-people) don’t have conflicting responsibilities or are in a position of opening the organization to risk.
Moreover, the individual responsible for designing and implementing security must not be the same person as the person responsible for testing security, conducting security audits or monitoring and reporting on security.
Separation of duties can be difficult to achieve with limited staff members, but controls should be put into place as much as possible to reduce the risk of a single point of compromise. You should assess the likelihood of a privileged activity causing a major impact to the business and build controls to reduce this likelihood or minimize the impact.
Dormant Identities
Dormant identities are characterized by a lack of login activity for a set amount of time, if at all. Malicious parties may access these identities –without the knowledge of their original owners – to conduct destructive activities to the organization’s systems, data security, and reputation. As such, they carry potential security risks to organizations.
It is necessary for cloud users to accurately identify and flag dormant identities to keep a close tab on them while subsequent activities are promptly stopped. Ideally, these identities can be removed altogether. Some possible solutions include ID-mapping on the cloud, where all identities are automatically sorted according to their business attributes or functions through classification, or by importing organizational charts, which recognizes identities based on the updated workflow.
Privilege Escalation
Privilege escalation occurs when a malicious user exploits a vulnerability, often an IAM misconfiguration, in the cloud. There are two types of privilege escalation, both having the potential to cause a great disruption to the user and organizational data.
Horizontal privilege escalation involves users with a limited account accessing another account with greater privileges. For example, a trial account user in a cloud environment might unlock and access the privileges of a premium user without payment.
Vertical privilege escalation presents more serious consequences, as malicious users gain the privileges of a power user, such as an account administrator. This means that malicious users can gain access to sensitive data and credentials. Malicious users may alter your environment for their benefit, steal privileged information, or erase vital data.
Toxic Combination
Toxic combinations involve the abuse of privileges enabled by SoD. For example, a user authorized to create an invoice might be mistakenly provided with the privilege of paying the bill. For example, IT users granted privileges to create identities should not be allowed to grant privileges to their created identities.
Reconsidering Default Settings in Google Cloud
There is often a false sense of security in assuming that functioning in the cloud the way it comes is secure. Often, an organization needs to evaluate if pre-determined or default settings actually work best for their environment. Consider these 4 areas of caution in GCP:
Generalized User Roles
Generalized user roles, like “Owner” or “Editor,” have broad privileges that unlock a number of resources. Sometimes a better alternative is using specific roles—either by creating custom roles or by using predefined roles from Google Cloud’s Identity and Access Management (IAM) portal.
As an example, if you’re working with a Cloud SQL database you can break identities up into more specific roles. For instance, you can give the role of cloudsql.editor to identities who need the privilege of creating new databases; the role of cloudsql.client to identities who need to connect to existing databases; and grant cloudsql.admin only to administrators of your databases – all opposed to just providing a general ‘Editor’ role.
Take Caution. In many cases, identity privileges can become extremely confusing. Unfortunately, the Google IAM documentation notes that these general roles are granted the ability to modify every resource in the project, creating substantial over permissions. Administrators should shy away from primitive roles and default service account identities, which rely on insecure defaults and are extremely privileged.
Permissions Groups Get Risky
In GCP, you can assign roles directly to individual users, but this practice is flawed if you’re looking to implement the POLP concept. The issue with assigning roles directly to individual users is that they will retain all rights granted by that role, even if you change their role later.
Instead, consider placing users into groups. You can create groups from within the Admin Console of your G Suite domain or from an external tool, like Active Directory. The use of groups can also help distribute ownership and avoid orphaned resources, a situation that occurs when the sole owner of a project or resource exits the organization. Group role management makes it easy to assign permissions at the resource, project, folder, or organizational level, making role management substantially easier for large organizations.
Take caution. These groups can be set at any level in the GCP resource hierarchy and are transitively inherited by descendant resources. This decentralization makes it difficult to enumerate all possible permissions granted to a member or group. Additionally, there are numerous ways for members to assume other members’ identities (e.g. service account impersonation), and permissions can be easily assigned across projects provided that the appropriate organization policy is disabled. This risk can easily scale with many projects.
Limit Service Accounts
Service accounts are intended for applications that need to access certain data. However, if a bad actor is able to get into a service account, they’ll be able to access anything the app was granted access to, like your company’s database. By default, the Compute Engine service account is given the role of editor and, unless you specifically disable it, it is enabled for all instances created in a project.
Instead of using the default service accounts in GCP, which could put your organization at risk, you should create a custom service account. This allows you to create instances with peace of mind and limit the role to the minimum privilege required. For instance, many Cloud SQL apps only need the cloudsql.client role, so the default editor role is poses as overkill.
Alternatively, you can grant the service account minimal access for the instance and instead create separate service accounts for each individual app, giving you very granular control over permissions. A word of caution that a service account can be hacked just like any other account, so you must maintain appropriate privilege and keep credentials secure using the right tools.
Use Networking Features to Control Resource Access
Communication across resources in Google Cloud Platform is made possible with a default network that connects your project’s resources together. This is ideal for development, but if you leave the network in its default configuration, you can easily give a bad actor a gateway from one resource to another and from one identity to another.
Take caution. Ideally, organizations would have formal policies for this escalation process and a CSPM solution for when drift occurs.
Get to Least Privilege and Stay There in Google Cloud
Organizations can achieve and maintain least privilege in the cloud with strong identity security through four steps:
- Relentless and Continuous Monitoring. Identity and data access should be monitored at all times with alerts being fired for events that deviate from your governance and operational models. Inactive or suspicious accounts should be swiftly detected and deactivated while identities should be constantly updated to fulfill the latest compliances through regulations such as the California Privacy Law and organizational mandates.
- Know Your Effective Permissions. Evaluating the risks of identities (people and non-people) across multiple public clouds, containing hundreds of accounts is challenging. Understanding all the effective permissions of an individual identity is a problem that cannot be solved by evaluating a single policy or calling an API. To manage this complexity and reduce risk to your identities and data, your organization should have end-to-end visibility into the trust relationships, as they truly exist in your environment. Without this visibility, you are operating more or less blindly.
- Enable your teams to be part of the solution. Your organization should shift left by integrating your Security, Cloud, Audit, IAM, and DevOps teams. Dev teams across your business populate your cloud with workloads and data in development, staging, and production. Some workloads access sensitive data while others do not. Some workloads are blocked from external access while others are not. Organize your different needs for monitoring and control.
- If there is an issue, fix it fast. Prevent the problem from happening in the first place, but if you missed it, close the gap quickly. Put prevention rules in place across your cloud and make sure they stay there. As people try to move workloads to production, use prevention bots to ensure checks are in place, and promotion only happens if your risk policies are followed. When possible, your organization should apply the policies to swimlanes to prevent the creation or change of risky cloud services and thus eliminate the possibility of risks being created in the first place.
POLP Tools For Google Cloud
Many organizations deploy and manage their applications on their own, but this means you are directly and solely responsible for configuring security settings and maintaining accounts and corresponding permissions.
If you choose to use a managed platform, like Cloud Run or Cloud Functions, you can take advantage of assistance and even automation tools that will help grant and revoke permissions. Likewise, you may consider moving to a fully managed service for your databases and processing frameworks, like Cloud SQL for MySQL and Postgres.
If you do continue to manage your own applications, it’s paramount that you not only understand the best practices of POLP but that you work hard to implement and maintain them as your identities and data change over time.
Sonrai’s recommendation is to use an identity and data security platform that can help you.
Take Advantage of POLP on Google Cloud
Ultimately, POLP is a process—not an initiative. It takes ongoing effort to ensure that identities always, and only, have the permissions they need to perform their immediate duties, and that requires processes, protocols, and proactive management.
Are you interested in learning more about the Principle of Least Privilege and how you can implement it for your Google Cloud (GCP) infrastructure? Ask one of our experts today and we’ll help get you on the right track.
The post Practicing The Principle of Least Privilege in Google Cloud appeared first on Sonrai Security.
*** This is a Security Bloggers Network syndicated blog from Blog - Sonrai Security authored by Eric Kedrosky. Read the original post at: https://sonraisecurity.com/blog/practicing-the-principle-of-least-privilege-in-google-cloud/