Slide thumbnail

Cập nhật kiến thức Google Cloud

Kiến thức

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

14/10/2019

Khi nói đến bảo mật, quản lý quyền truy cập là một khả năng nền tảng – cho dù bạn đang nói về một không gian vật lý hay cơ sở hạ tầng đám mây của bạn. Nếu bạn đang bảo vệ một văn phòng, bạn sẽ cung cấp cho mỗi nhân viên một chìa khóa chính có thể mở cửa trước, hộp thư và két sắt. Tương tự như vậy, khi bạn đang bảo vệ cơ sở hạ tầng đám mây của mình, bạn nên hạn chế nhân viên truy cập vào mạng dựa trên vai trò của họ và những gì họ yêu cầu để thực hiện công việc của họ.

Khái niệm này được gọi là nguyên tắc đặc quyền tối thiểu, mà Trung tâm tài nguyên bảo mật máy tính của NIST định nghĩa là: Một nguyên tắc bảo mật giới hạn các đặc quyền truy cập của nhân viên được ủy quyền … đến mức tối thiểu cần thiết để thực hiện công việc của họ. “Trong thực tế, điều này có nghĩa là chỉ gán thông tin xác thực và đặc quyền khi cần thiết cho cả người dùng và dịch vụ và xóa mọi quyền không còn cần thiết.

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. 

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: Tránh sử dụng quá nhiều primitive roles

Primitive roles như Owner và Editor cấp quyền truy cập trên phạm vi rộng cho tất cả các tài nguyên dự án. Để thắt chặt bảo mật truy cập, hãy xem xét sử dụng các  predefined roles cụ thể hơn trong Cloud Identity and Access Management (IAM) hoặc định nghĩa các 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 cho người dùng tạo cơ sở dữ liệu mới, cloudsql.client cho những người chỉ cần kết nối với hiện có cơ sở dữ liệu và giới hạn cloudsql.admin cho người quản trị cơ sở dữ liệu.

 

Trang thiết kế chính sách của Google có một số cấu trúc và chính sách mẫu cho các loại tổ chức khác nhau, bao gồm các công ty mới khởi nghiệp, doanh nghiệp lớn và giáo dục và đào tạo khách hàng.

#2: Gán roles cho nhóm, không gán cho cá nhân

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:

Nếu bạn chỉ định IAM role trực tiếp cho một cá nhân, họ sẽ giữ các quyền được cấp bởi vai trò đó ngay cả khi họ thay đổi vai trò, di chuyển xung quanh tổ chức của bạn hoặc không còn yêu cầu họ nữa. Một lựa chọn an toàn hơn và dễ bảo trì hơn là đặt người dùng vào các nhóm logic. Ví dụ: để quản lý cơ sở dữ liệu, bạn có thể tạo db-editors, db-viewersdb-admins và cho phép người dùng kế thừa vai trò từ các nhóm này:

 

Một ví dụ về việc chỉ định người dùng và vai trò vào các nhóm

 

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 nào hoặc được liên kết từ một công cụ bên ngoài như Active Directory. Bằng cách sử dụng các nhóm để sở hữu, bạn cũng có thể tránh được các dự án và tài nguyên của mồ côi – trong đó một dự án hoặc tài nguyên có một chủ sở hữu rời khỏi tổ chức.

Bạn có thể gán vai trò ở cấp độ tổ chức, thư mục, dự án hoặc tài nguyên. Điều này cho phép các tổ chức lớn hơn dễ dàng quản lý vai trò cho một nhóm nhà phát triển cụ thể hoặc toàn bộ bộ phận kế toán. Tuy nhiên, hãy lưu ý rằng tài nguyên con không thể giới hạn các vai trò do cha mẹ cấp: ví dụ: vai trò cloudsql.viewer cấp độ dự án của người dùng sẽ ghi đè mọi giới hạn cấp tài nguyên trên bất kỳ cơ sở dữ liệu nào trong cùng dự án.

#3: Giảm rủi ro của hành vi default service account

Tài khoản dịch vụ (Service accounts) là một loại tài khoản đặc biệt dành cho các ứng dụng cần truy cập dữ liệu. Tuy nhiên, nếu thông tin cá nhân của ứng dụng bị xâm phạm, kẻ tấn công sẽ có tất cả quyền truy cập được cấp cho ứng dụng bởi vai trò của tài khoản dịch vụ.

Tài khoản dịch vụ mặc định của Compute Engine, có vai trò editor, được bật cho tất cả các instance được tạo trong một dự án trừ khi bạn chỉ định khác.

Default service account có quyền chỉnh sửa cho tất cả tài nguyên trong dự án.

 

Tạo một tài khoản dịch vụ tùy chỉnh để sử dụng để tạo các phiên bản và giới hạn vai trò của nó ở mức tối thiểu cần thiết giúp giảm đáng kể rủi ro. Ví dụ: nhiều ứng dụng sử dụng Cloud SQL chỉ cần vai trò cloudsql.client cho phép chúng kết nối với cơ sở dữ liệu hiện có.

 

Với tài khoản dịch vụ tùy chỉnh, bạn có thể cấp các đặc quyền tối thiểu cần thiết cho các phiên bản và ứng dụng.

 

Một cách tiếp cận khác là cấp các đặc quyền tối thiểu cho tài khoản dịch vụ cá nhân và tạo các tài khoản dịch vụ dành riêng cho ứng dụng của bạn. Điều này mang lại cho bạn quyền kiểm soát chi tiết hơn đối với từng đặc quyền của ứng dụng, mặc dù bạn sẽ cần quản lý cẩn thận thông tin đăng nhập tài khoản dịch vụ.

#4: Giảm rủi ro và kiểm soát truy cập vào dự án của bạn bằng cách sử dụng các tính năng mạng

Để cho phép liên lạc giữa các tài nguyên, các dự án GCP mới ban đầu có một mạng mặc định kết nối tất cả các tài nguyên trong dự án đó. Điều này thuận tiện cho việc phát triển, nhưng trong cấu hình mặc định này, nếu kẻ tấn công có quyền truy cập trái phép vào một tài nguyên, chúng cũng có thể tiếp cận với những người khác.

Để hạn chế rủi ro này, không sử dụng mạng mặc định trong môi trường chính thức và chỉ định rõ ràng phạm vi, cổng và giao thức IP nguồn được chấp nhận trong tường lửa mạng. Bạn cũng nên tách các ứng dụng nhạy cảm thành các đám mây riêng ảo (VPC) riêng lẻ và nếu cần kết nối giữa các ứng dụng, hãy sử dụng VPC được chia sẻ. Trong mỗi VPC, sử dụng các mạng con khác nhau cho các dịch vụ đối mặt công khai (ví dụ: máy chủ web và máy chủ pháo đài) và dịch vụ phụ trợ riêng. Chỉ phân bổ IP công cộng cho các phiên bản trong mạng con công cộng và thêm quy tắc tường lửa bằng thẻ mạng để kiểm soát dịch vụ nào có thể giao tiếp với nhau. Cuối cùng, cấp quyền để tạo hoặc sửa đổi tường lửa và tuyến đường chỉ cho những người chịu trách nhiệm trực tiếp cho mạng.

 

Một ví dụ về việc hạn chế truy cập với các tường lửa và các mạng con công cộng và riêng tư.

 

Các ứng dụng và trường hợp bảo mật với bảng mã mạng tùy chỉnh sẽ hướng dẫn bạn thông qua việc thiết lập cấu hình mạng con công khai / riêng tư ở trên. Thiết kế chính sách cho bài viết của khách hàng mà google đã đề cập trước đó cũng chứa các thiết kế mạng mẫu cho các trường hợp sử dụng phổ biến. Để được hướng dẫn về sự đánh đổi của các VPC đơn, nhiều và chia sẻ, hãy xem các thực tiễn tốt nhất và các kiến trúc tham khảo cho thiết kế VPC.

#5: Cân nhắc sử dụng các nền tảng và dịch vụ đã được quản lý

Nếu bạn triển khai và quản lý các ứng dụng của riêng mình, bạn chịu trách nhiệm về cấu hình bảo mật, bao gồm cả việc duy trì tài khoản và quyền. Bạn có thể giới hạn trách nhiệm của mình bằng cách lưu trữ ứng dụng của mình trên các nền tảng được quản lý như Cloud Run, App Engine hoặc Cloud Function hoặc bằng cách sử dụng các dịch vụ được quản lý hoàn toàn cho cơ sở dữ liệu và khung xử lý như Cloud SQL cho MySQL và Postgres, Cloud Dataproc cho Hadoop và Spark và Cloud Memorystore for Redis.

Lưu ý cuối cùng

Bảo mật là ưu tiên hàng đầu trong tất cả các khía cạnh của Google Cloud, nhưng bảo mật đám mây là trách nhiệm chung và cuối cùng, bạn có trách nhiệm đưa ra các lựa chọn sản phẩm và cấu hình phù hợp cho tổ chức của mình để bảo vệ dữ liệu của bạn trên GCP. Những lời khuyên này là điểm khởi đầu tuyệt vời để giúp giảm bề mặt tấn công của bạn và giúp bạn đưa ra quyết định rủi ro sáng suốt hơn. Để biết thêm tài nguyên và giải pháp bảo mật cho doanh nghiệp của bạn, hãy chắc chắn kiểm tra trang Trust & Security của Google.

 

Gimasys.