skip to Main Content
Welcome to Gimasys!
Hotline: +84 974 417 099 (HCM) | +84 987 682 505 (HN) gcp@gimasys.com

[Thông tin] Thực hành nguyên tắc đặc quyền tối thiểu

Thực hành nguyên tắc đặc quyền tối thiểu 1

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.

Hãy luôn nhớ nguyên tắc đặc quyền tối thiểu, dưới đây là năm mẹo thiết thực để giảm thiểu diện tích bề mặt của tài nguyên bị lộ trên Google Cloud Platform (GCP) và bảo vệ chống lại một số cuộc tấn công phổ biến.

#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 phù hợp hơn với tổ chức của bạn. Ví dụ: nếu bạn có cơ sở dữ liệu Cloud SQL, thay vì cấp vai trò Trình soạn thảo trong toàn dự án cho mọi người, bạn có thể cấp vai trò 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.

Thực hành nguyên tắc đặc quyền tối thiểu 2

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 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
An example of assigning users and roles to groups

Các nhóm có thể được tạo trong Bảng điều khiển dành cho quản trị viên cho bất kỳ tên miền G Suite (Google Workspace customers) nào hoặc 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.

Tài khoản dịch vụ mặc định của Compute Engine, 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.
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.
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.
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.

Update: Gimasys

Back To Top
0974 417 099