Practice the principle of least privilege

When it comes to security, access management is a cornerstone capability – whether you're talking about a physical space or your cloud infrastructure. If you are securing an office, you will provide each employee with a master key that can open the front door, mailbox, and safe. Likewise, when you're protecting your cloud infrastructure, you should restrict employees' access to the network based on their roles and what they require to do their jobs.

This concept is called the principle of least privilege, which NIST's Computer Security Resource Center definition is: A security principle that limits the access privileges of authorized personnel… to the minimum level necessary to perform their job. “In practice, this means assigning credentials and privileges only when necessary to both the user and the service, and removing any permissions that are no longer needed.

Keeping the principle of least privilege in mind, here are five practical tips to minimize the surface area of exposed resources on Google Cloud Platform (GCP) and defend against some common attacks. 

Keeping the principle of least privilege in mind, here are five practical tips to reduce the surface area of exposed resources on Google Cloud Platform (GCP) and protect against some common attacks.

#1: Avoid using too many primitive roles

Primitive roles as Owner and Editor grant broad access to all project resources. To tighten access security, consider using the  predefined roles more specifically in Cloud Identity and Access Management (IAM) or define the custom roles more relevant to your organization. For example, if you have a Cloud SQL database, instead of giving everyone the Project-wide Editor role, you could grant the cloudsql.editor for the user to create a new database, cloudsql.client for those who just need to connect to existing and limited databases cloudsql.admin for database administrators.

 

Policy design page Google's has several sample structures and policies for different types of organizations, including startups, large enterprises, and customer education and training.

#2: Assign roles to groups, not individuals

If you assign an IAM role directly to an individual, they retain the rights granted by that role even if they change roles, move around your organization, or no longer require them. A safer and more maintainable option is to place users into logical groups. For example, to manage databases, you could create db-editors, db-viewers, and db-admins groups, and let users inherit roles from these groups:

If you assign the IAM role directly to an individual, they will keep the permissions granted by that role even if they change roles, move around your organization, or no longer require them. A safer and more maintainable option is to put users in logical groups. For example, to manage a database, you can create db-editors, db-viewers and db-admins and allow users to inherit roles from these groups:

 

An example of assigning users and roles to groups

 

Groups can be created in the Admin console for any G Suite domain or linked from an external tool such as Active Directory. By using groups for ownership, you can also avoid orphan projects and resources – where a project or resource has an owner leaving the organization.

You can assign roles at the organization, folder, project, or resource level. This allows larger organizations to easily manage roles for a specific group of developers or an entire accounting department. Note, however, that child resources cannot be limited to parent-granted roles: e.g. role cloudsql.viewer the user's project level overrides any resource level restrictions on any database in the same project.

#3: Reduce the risk of default service account behavior

Service account (Service accounts) is a special type of account for applications that need to access data. However, if the private information of the application is compromised, the attacker will have all the access rights granted to the application by the service account role.

Compute Engine default service account, important editor, is enabled for all instances created in a project unless you specify otherwise.

The default service account has edit permissions for all resources in the project.

 

Create a custom service account to use to create versions and limited its role to the minimum necessary to significantly reduce risk. For example, many applications using Cloud SQL only need roles cloudsql.client allow them to connect to an existing database.

 

With a custom service account, you can grant the minimum privileges required for instances and applications.

 

Another approach is to grant minimum privileges to individual service accounts and create your application-specific service accounts. This gives you more fine-grained control over each app's perks, although you'll need to Careful management service account login information.

#4: Reduce risk and control access to your project using network features

To enable communication between resources, new GCP projects initially have a default network connect all the resources in that project. This is convenient for development, but in this default configuration, if an attacker has unauthorized access to a resource, they can also reach others.

To limit this risk, do not use the default network in the official environment and explicitly specify the acceptable source IP ranges, ports, and protocols in network firewall. You should also separate sensitive applications into virtual private cloud (VPC) individually, and if interconnection between applications is required, use Shared VPC. In each VPC, use the Subnet different for public facing services (e.g. web servers and fortress server) and its own ancillary service. Allocate public IP to instances in public subnet only and add firewall rule with network card to control which services can communicate with each other. Finally, grant permission to create or modify firewalls and routes only to those directly responsible for the network.

 

An example of access restriction with firewalls and public and private subnets.

 

Security applications and scenarios with custom network encoding will guide you through setting up the above public/private subnet configuration. Design policy for customer articles which google mentioned earlier also contains sample network designs for common use cases. For guidance on the trade-offs of single, multiple, and shared VPCs, seeBest practices and reference architectures for VPC design.

#5: Consider using managed platforms and services

If you deploy and manage your own applications, you are responsible for the security configuration, including maintaining accounts and permissions. You can limit your liability by hosting your application on regulated platforms like Cloud Run, App Engine or Cloud Functions or by using fully managed services for databases and processing frameworks like Cloud SQL for MySQL and Postgres, Cloud Dataproc for Hadoop and Spark and Cloud Memorystore for Redis.

Final Note

Security is a top priority in all aspects of Google Cloud, but cloud security is a shared responsibility, and it is ultimately your responsibility to make the right configuration and product choices for your organization to protect your data on GCP. These tips are a great starting point to help reduce your attack surface and help you make more informed risk decisions. For more resources and security solutions for your business, be sure to check out the page Trust & Security by Google.

 

Gimasys.