CMC Telecom cam kết hỗ trợ doanh nghiệp của bạn kịp thời
Hãy gửi phản hồi và câu hỏi của bạn cho chúng tôi để được giải đáp
Tóm tắt nội dung
Bài viết phân tích các rủi ro bảo mật phổ biến khi sử dụng Google Cloud Platform (GCP), trong đó 86% trường hợp bị xâm phạm được dùng để khai thác tiền điện tử (Cryptojacking). Nguyên nhân chính bao gồm: mật khẩu yếu (48%), lỗ hổng phần mềm bên thứ ba (26%), và rò rỉ thông tin đăng nhập trên GitHub (4%). Bài viết đi sâu vào vấn đề rò rỉ Service Account key, một trong những nguyên nhân nghiêm trọng nhất và đồng thời hướng dẫn cách khắc phục khi bị tấn công và các biện pháp phòng ngừa bao gồm: sử dụng Workload Identity Federation, áp dụng nguyên tắc quyền tối thiểu, mã hóa key bằng Cloud Secret Manager, thiết lập Organization Policies và Quotas.

Theo báo cáo mới nhất của Đội Hành động An ninh mạng từ CMC Telecom, 86% trong số tài khoản Google Cloud bị hack gần đây được dùng để đào tiền mã hóa. Các hacker đã tải phần mềm đào tiền xuống trong vòng 22 giây sau khi hack thành công tài khoản. Nếu tài khoản Google Cloud bị hack để đào tiền ảo, người dùng sẽ phải trả phí tăng vọt (có thể lên đến hàng tỷ đồng) trong thời gian ngắn và có thể bị mất dữ liệu quan trọng.
Service account là một loại tài khoản đặc biệt trên Google Cloud Platform (GCP) được sử dụng để xác thực và ủy quyền cho các ứng dụng và dịch vụ. Service account có thể được tạo và quản lý bởi người dùng hoặc bởi Google.
Một trong những cách phổ biến để cho phép một ứng dụng xác thực như một service account là tạo một khóa service account key và sử dụng nó để lấy các mã thông báo truy cập OAuth 2.0. Có một số cách mà hacker có thể có được thông tin service account, chẳng hạn như:
Việc bị lộ Service Account sẽ tạo điều kiện cho các hacker có thể thâm nhập vào hệ thống GCP để từ đó có thể tận dụng tài nguyên để khai thác tiền điện tử. Cách thức này được gọi là Cryptojacking. Để sử dụng service account bị lộ để khai thác tiền điện tử, hacker có thể làm như sau:
Nguyên nhân chính của việc lộ thông tin service account là do việc quản lý không an toàn của service account key. Có nhiều trường hợp có thể dẫn đến việc này, ví dụ:
Đây là một vấn đề an ninh nghiêm trọng và có thể gây ra thiệt hại lớn cho người dùng GCP. Trong phần 2, CMC sẽ đưa ra cách khắc phục hậu quả và cách phòng ngừa vấn đề này.

Nếu phát hiện ra service account key đã bị lộ, những việc sau cần xử lý ngay lập tức:
gcloud compute instances delete và cung cấp các tên của các VMs muốn xóa. Có thể sử dụng các tùy chọn như --zone, --quiet, --delete-disks để điều chỉnh việc xóa. Ví dụ:
gcloud compute instances delete vm1 vm2 vm3 --zone us-central1-a --quiet --delete-disks all
Để ngăn chặn việc lộ thông tin service account trong tương lai, các biện pháp sau cần được áp dụng:
(*) Workload identity federation là một tính năng cho phép bạn xác thực như một service account từ một workload bên ngoài GCP. Sử dụng workload identity federation để liên kết một identity provider với một service account và cho phép workload yêu cầu mã thông báo truy cập từ identity provider. Điều này sẽ giúp loại bỏ việc sử dụng và quản lý service account key cho các workload bên ngoài GCP.
(**) Service account impersonation là một tính năng cho phép xác thực như một service account từ một người dùng hoặc một service account khác. Sử dụng service account impersonation để ủy quyền cho một người dùng hoặc một service account khác để thực hiện các hành động thay mặt cho một service account. Điều này sẽ giúp kiểm soát quyền truy cập của service account và tránh việc phân phối service account key cho nhiều người dùng hoặc service account khác.
Cloud Secret Manager là một dịch vụ của GCP cho phép quản lý, lưu trữ, và quản lý các bí mật nhạy cảm như mật khẩu, khóa mã hóa, hoặc các giá trị đăng nhập. Bạn có thể sử dụng Cloud Secret Manager để bảo mật các thông tin nhạy cảm liên quan đến Service Account, và có thể tích hợp nó vào Terraform để quản lý các tài nguyên trong GCP. Dưới đây là các bước để tạo và sử dụng Cloud Secret Manager trong Terraform:
Bước 1: Tạo và lưu trữ secret value trong Cloud Secret Manager
Bước 2: Đọc secret value từ Cloud Secret Manager trong Terraform:
Sử dụng google_secret_manager_secret_version resource trong Terraform để đọc giá trị bí mật từ Cloud Secret Manager. Định nghĩa resource tương ứng với bí mật và phiên bản của nó trong Terraform. Ví dụ:
resource "google_secret_manager_secret_version" "my_service_account_key" {
secret = "my-service-account-key"
version = "latest"
}
Bước 1: Vào trang Organization Policies trong Google Cloud Console.
Bước 2: Chọn tổ chức hoặc project muốn áp dụng chính sách.
Bước 3: Chọn loại chính sách Restrict Resource Locations.
Bước 4: Chọn nút Edit để chỉnh sửa chính sách.
Bước 5: Nhập các giá trị cho các vùng (region) hoặc khu vực (zone) mà cho phép hoặc cấm tạo tài nguyên. Sử dụng các tiền tố như in:, not-in:, has:, not-has: để lọc các giá trị. Ví dụ: in:us-locations, not-in:asia-southeast1-a, has:europe, not-has:southamerica.
Bước 6: Nhấn nút Save để lưu lại chính sách.
Bước 1: Vào trang Quotas trong Google Cloud Console.
Bước 2: Chọn project muốn thiết lập giới hạn quotas.
Bước 3: Chọn loại tài nguyên, vd: Compute Engine API.
Bước 4: Tìm và chọn giới hạn thay đổi, ví dụ Quota: VM Instances.
Bước 5: Nhấn nút Edit Quotas để chỉnh sửa giới hạn.
Bước 6: Nhập số lượng tối đa cho phép cho loại tài nguyên đó. Ví dụ: 10.
Bước 7: Submit Request để gửi yêu cầu thay đổi giới hạn.
CMC Telecom sẽ hỗ trợ khách hàng trong việc review cũng như cùng với Khách hàng hỗ trợ việc thiết lập Policies và Quotas sao cho hợp lý.
Hãy gửi phản hồi và câu hỏi của bạn cho chúng tôi để được giải đáp