---
title: "Danh sách kiểm tra tăng cường bảo mật GCP | Snow Tree"
url: "https://www.snow-tree.com/vi/gcp-security-hardening/"
---

Cơ sở hạ tầng GCP an toàn

# Danh sách kiểm tra tăng cường bảo mật GCP cho các nhóm vừa và nhỏ

Một đường cơ sở thực tế cho các nhóm chạy khối lượng công việc trong môi trường sản xuất trên Google Cloud mà không có bộ phận bảo mật chuyên trách. Hãy bắt đầu từ những chỗ mà các con đường dễ dẫn đến sự cố nghiêm trọng nhất cũng là dễ thu hẹp nhất.

## Trên trang này

1. [Các con đường đe dọa phổ biến trên GCP](https://www.snow-tree.com/vi/#threat-paths)
2. [Danh tính và quyền truy cập](https://www.snow-tree.com/vi/#identity)
3. [Mạng và biên](https://www.snow-tree.com/vi/#network)
4. [Dữ liệu và bí mật](https://www.snow-tree.com/vi/#data)
5. [Tăng cường bảo mật GKE](https://www.snow-tree.com/vi/#gke)
6. [Phát hiện và phục hồi](https://www.snow-tree.com/vi/#detection)
7. [Danh sách kiểm tra ưu tiên 30, 60 và 90 ngày](https://www.snow-tree.com/vi/#checklist)
8. [Tài liệu tham khảo chính thức](https://www.snow-tree.com/vi/#references)

## Các con đường đe dọa phổ biến trên GCP

Hầu hết các sự cố trên đám mây đều bắt đầu từ một lỗ hổng nhỏ về quyền sở hữu hoặc cấu hình. Hãy tìm ra những con đường này trước khi kẻ tấn công tìm ra.

- Một người dùng, tài khoản dịch vụ hoặc danh tính khối lượng công việc được cấp quyền quá mức có thể biến một thông tin xác thực bị đánh cắp thành quyền truy cập rộng trên nhiều dự án.
- Một điểm cuối quản lý bị lộ, một cổng gỡ lỗi hoặc một quy tắc tường lửa quá lỏng lẻo có thể vượt qua mọi biện pháp kiểm soát được thiết kế cho lưu lượng ứng dụng thông thường.
- Một bộ chứa lưu trữ công khai hoặc một URL đã ký có phạm vi quá rộng có thể làm lộ dữ liệu khách hàng mà không có dấu hiệu rõ ràng nào cho thấy ứng dụng bị xâm phạm.
- Các khối lượng công việc cũ tạo ra rủi ro lâu dài khi image cũ, không gian tên bị lãng quên, tài khoản dịch vụ không dùng đến và tài nguyên không có chủ sở hữu vẫn có thể được triển khai.
- Bằng chứng kiểm tra bị thiếu hoặc chỉ được lưu giữ trong thời gian ngắn khiến việc xác định ai đã thay đổi chính sách, quyền truy cập bắt đầu từ khi nào và dữ liệu nào đã bị tiếp cận trở nên khó khăn.
- Một bản sao lưu chưa được kiểm thử chỉ là một niềm hy vọng. Khôi phục thất bại, lưu giữ không đầy đủ và khóa mã hóa không thể truy cập có thể biến một sự kiện bảo mật thành tổn thất vĩnh viễn.

## Danh tính và quyền truy cập

Hãy coi danh tính là mặt phẳng điều khiển chính. Mỗi con người, quy trình tự động hóa và khối lượng công việc cần có một danh tính riêng biệt với mục đích giới hạn.

### Làm rõ ranh giới tài nguyên

Sử dụng tổ chức (organization) và thư mục để đặt các rào chắn bảo vệ, đồng thời tách môi trường phát triển, staging và sản xuất thành các dự án riêng hoặc các ranh giới tin cậy chặt chẽ hơn. Áp dụng chính sách tổ chức ở cấp cao nhất có thể, hạn chế việc sử dụng dịch vụ và tránh dùng chung dự án sản xuất giữa các sản phẩm không liên quan.

### Cấp vai trò tối thiểu ở phạm vi hẹp nhất

Ưu tiên các vai trò được xác định trước hoặc vai trò tùy chỉnh thay vì các vai trò cơ bản có phạm vi rộng, cấp chúng cho nhóm và danh tính khối lượng công việc, đồng thời sử dụng điều kiện IAM ở những nơi tên tài nguyên hoặc thẻ có thể thu hẹp quyền truy cập. Xem xét các quyền không được sử dụng và loại bỏ quyền truy cập thường trực vào môi trường sản xuất vốn chỉ nên thuộc về quy trình truy cập khẩn cấp (break-glass).

### Xóa thông tin xác thực tồn tại lâu dài

Sử dụng Workload Identity Federation for GKE để các Pod nhận được thông tin xác thực ngắn hạn mà không cần khóa tài khoản dịch vụ được xuất ra. Chặn việc tạo và tải lên khóa bằng chính sách tổ chức khi có thể, kiểm kê mọi khóa còn lại và cảnh báo về các thay đổi IAM có rủi ro cao trong Cloud Audit Logs.

## Mạng và biên

Hãy giả định rằng sớm muộn gì một lỗi nào đó của ứng dụng cũng có thể bị tiếp cận từ mạng. Hãy giới hạn những gì lỗi đó có thể truy cập.

### Bắt đầu bằng từ chối mặc định, rồi thêm từng đường dẫn được chỉ định

Sử dụng các quy tắc tường lửa VPC theo nguyên tắc đặc quyền tối thiểu và Kubernetes NetworkPolicies cho lưu lượng của Pod. Tách các môi trường thành các mạng riêng biệt, ghi lại mọi đường dẫn ingress và loại bỏ các quy tắc gỡ lỗi phạm vi rộng cho phép các cổng quản lý hoặc mọi giao thức từ những dải địa chỉ lớn.

### Giữ các nút và mặt phẳng điều khiển ở chế độ riêng tư

Vô hiệu hóa địa chỉ IP bên ngoài trên các nút GKE. Ưu tiên điểm cuối mặt phẳng điều khiển riêng tư dựa trên DNS, và khi không thể tránh dùng điểm cuối IP, hãy hạn chế nó bằng các mạng được ủy quyền. Cung cấp cho khối lượng công việc một đường egress có chủ đích thay vì quyền truy cập Internet rộng rãi.

### Chỉ công khai những dịch vụ được chủ đích công khai

Công khai ứng dụng thông qua một gateway hoặc bộ cân bằng tải đã được xem xét, chứ không phải qua địa chỉ Pod hoặc nút ngẫu nhiên. Kết thúc TLS bằng chứng chỉ được quản lý, hạn chế host và đường dẫn ingress, áp dụng giới hạn yêu cầu và giới hạn tốc độ, đồng thời đặt các giao diện quản trị phía sau cơ chế truy cập nhận biết danh tính.

## Dữ liệu và bí mật

Bảo vệ dữ liệu khi lưu trữ, khi truyền và khi sử dụng, sau đó chứng minh rằng bạn có thể khôi phục dữ liệu đó. Việc phát hiện dữ liệu cũng là một phần của biện pháp kiểm soát.

### Ngăn chặn truy cập công khai ngoài ý muốn

Thực thi tính năng ngăn chặn truy cập công khai và quyền truy cập đồng nhất cấp bộ chứa trên Cloud Storage. Phân loại bộ chứa theo mức độ nhạy cảm, hạn chế quyền truy cập vào đối tượng và khóa, bật ghi nhật ký cho dữ liệu có giá trị cao và sử dụng khóa mã hóa do khách hàng quản lý khi mô hình rủi ro hoặc tuân thủ của bạn yêu cầu.

### Không để thông tin bí mật trong image và mã nguồn

Lưu trữ thông tin xác thực trong Secret Manager và chỉ cấp quyền truy cập cho một danh tính khối lượng công việc cụ thể và một phiên bản bí mật cụ thể. Xoay vòng bí mật một cách có chủ đích, tránh sao chép chúng vào Git hoặc image container, và đừng coi Kubernetes Secrets thông thường là một ranh giới bảo vệ hoàn chỉnh.

### Kiểm thử việc khôi phục, không chỉ việc tạo bản sao lưu

Xác định mục tiêu điểm khôi phục (RPO) và thời gian khôi phục (RTO), giữ các bản sao bên ngoài miền lỗi của môi trường sản xuất, và bảo vệ quyền truy cập vào bản sao lưu và khóa mã hóa khỏi danh tính khối lượng công việc. Định kỳ khôi phục vào một môi trường biệt lập, xác minh dữ liệu, ghi lại thời gian đã mất và mọi bước thủ công.

## Tăng cường bảo mật GKE

GKE bảo mật mặt phẳng điều khiển được quản lý, nhưng cấu hình cụm, không gian tên, chính sách kiểm soát tiếp nhận (admission) và khối lượng công việc vẫn thuộc trách nhiệm quản lý của bạn.

### Dùng không gian tên làm ranh giới cách ly đã cam kết

Tách các nhóm và môi trường thành các không gian tên hoặc cụm, ràng buộc các vai trò Kubernetes RBAC hẹp ở đó và áp dụng hạn ngạch tài nguyên cũng như NetworkPolicies. Tránh truy cập ghi trên toàn cụm để phân phối ứng dụng và cấp cho mỗi khối lượng công việc tài khoản dịch vụ riêng khi cần một danh tính riêng biệt.

### Chỉ cho phép những image và cấu hình bạn tin cậy

Thực thi tiêu chuẩn Pod Security ở mức restricted hoặc các quy tắc Policy Controller tương đương. Triển khai image theo digest bất biến, quét lỗ hổng cho chúng, sử dụng Binary Authorization khi nguồn gốc là quan trọng, và từ chối quyền truy cập host ngoài dự kiến, leo thang đặc quyền và các liên kết cluster-admin.

### Loại bỏ quyền hạn container không cần thiết

Chạy với người dùng không phải root, loại bỏ các Linux capabilities, sử dụng hệ thống tệp gốc chỉ đọc khi có thể và áp dụng hồ sơ seccomp RuntimeDefault. Không gắn mã thông báo tài khoản dịch vụ khi không cần thiết, tránh container đặc quyền và không gian tên của host, giữ quyền của tài khoản dịch vụ nút ở mức tối thiểu, và sử dụng Shielded Nodes cùng với Container-Optimized OS.

## Phát hiện và phục hồi

Các biện pháp kiểm soát rồi cũng có lúc thất bại. Hãy dựa vào bằng chứng và các hành động đã được diễn tập, chứ không phải niềm tin rằng chưa ai mắc sai lầm.

### Thu thập bằng chứng bạn sẽ cần

Lưu giữ Cloud Audit Logs cùng nhật ký hệ thống và nhật ký khối lượng công việc của GKE tại một đích tập trung, với thời gian lưu giữ phù hợp với nhu cầu điều tra của bạn. Bật nhật ký Truy cập dữ liệu (Data Access) có chọn lọc cho dữ liệu nhạy cảm, hạn chế quyền truy cập nhật ký và ghi lại các thay đổi quản trị đối với IAM, tường lửa, bộ lưu trữ và cấu hình cụm.

### Cảnh báo những thay đổi có ý nghĩa bảo mật

Cảnh báo khi bộ lưu trữ bị công khai, khi có thay đổi tường lửa hoặc IAM trên phạm vi rộng, khóa tài khoản dịch vụ ngoài dự kiến, các lần từ chối admission, mặt phẳng điều khiển bị lộ, xác thực thất bại lặp lại, ghi nhật ký bị tắt, sao lưu thất bại và chứng chỉ sắp hết hạn. Chuyển từng cảnh báo đến một người phụ trách kèm theo các bước để xác nhận hoặc bác bỏ cảnh báo đó.

### Luyện tập phản hồi

Viết các runbook ngắn cho các trường hợp thông tin xác thực bị rò rỉ, dữ liệu bị công khai, khối lượng công việc bị xâm phạm và mất khu vực hoặc dự án. Nêu rõ ai có thể cho phép ngăn chặn sự cố, cách thu hồi quyền truy cập, cách bảo toàn bằng chứng và cách khôi phục dịch vụ. Kiểm thử các runbook cùng với những người sẽ sử dụng chúng.

## Danh sách kiểm tra ưu tiên 30, 60 và 90 ngày

Nếu bạn đang bắt đầu từ một đường cơ sở chưa đầy đủ, hãy sắp xếp thứ tự công việc để giảm mức độ phơi nhiễm trước, rồi giúp các lần rà soát sau có thể lặp lại.

### Ngày 1 đến 30: chặn những con đường hiển nhiên

Kiểm kê các dự án và chủ sở hữu, xóa thông tin xác thực không dùng đến và tồn tại lâu dài, xác nhận việc ghi nhật ký kiểm tra, chặn các bộ chứa công khai, rà soát các quy tắc tường lửa và quyền IAM được cấp rộng nhất, xác định các thiếu sót trong sao lưu môi trường sản xuất và khắc phục mọi điểm cuối công khai không có chủ sở hữu. Giao người phụ trách và hạn hoàn thành cho từng phát hiện.

### Ngày 31 đến 60: làm cho đường cơ sở có thể lặp lại

Chuyển cấu hình mạng, danh tính và khối lượng công việc sang cơ sở hạ tầng dưới dạng mã đã được xem xét và phân phối bằng GitOps. Áp dụng Workload Identity, nút riêng tư, Pod Security ở mức restricted, kiểm tra image đáng tin cậy, nhật ký tập trung và cảnh báo cho những thay đổi quan trọng nhất.

### Ngày 61 đến 90: chứng minh và duy trì nó

Chạy các bài kiểm thử khôi phục và một buổi diễn tập sự cố dạng tabletop, rà soát quyền truy cập đặc quyền và thời hạn của các ngoại lệ, quét lại image và các phần phụ thuộc, xác minh rằng chủ sở hữu nhận được cảnh báo và đo lường các thiếu sót còn lại. Đưa các bước kiểm tra vào chu kỳ rà soát định kỳ trước khi bằng chứng trở nên lỗi thời.

Hãy sử dụng danh sách kiểm tra này làm điểm khởi đầu. Snow Tree có thể áp dụng đường cơ sở thông qua dịch vụ vận hành Nền tảng được quản lý hoặc một dự án tư vấn tập trung.

[Nền tảng được quản lý](https://www.snow-tree.com/vi/managed-platform/) [Tư vấn](https://www.snow-tree.com/vi/consulting/)

## Tài liệu tham khảo chính thức

Sử dụng hướng dẫn hiện tại của Google làm nguồn thông tin kỹ thuật đáng tin cậy khi các giá trị mặc định của nền tảng hoặc khả năng của sản phẩm thay đổi.

- [Google Cloud: Các phương pháp hay nhất để tăng cường bảo mật cho cụm GKE của bạn](https://docs.cloud.google.com/kubernetes-engine/docs/how-to/hardening-your-cluster)
- [Google Cloud: Các phương pháp hay nhất về bảo mật GKE](https://docs.cloud.google.com/docs/security/gke-security-bps)

Nền tảng được quản lý

## Để Snow Tree xây dựng, lưu trữ và vận hành phần mềm.

[Bắt đầu dự án](mailto:support+snow-tree-platform-1-issue-@gitlab.snow-tree.com?subject=Snow%20Tree%20project)