Landing Zone trên Google Cloud: Part 2: Identity
Anh là ai, ở đây làm gì, xuất trình giấy tờ ra đây
Trong phần trước chúng ta đã tìm hiểu cơ bản về khái niệm Landing Zone, tại sao chiến lược cloud nên bắt đầu với Landing Zone và 4 cấu phần cốt lõi của kiến trúc này trên Google Cloud. Trong các bài viết tiếp theo, mình sẽ đi sâu vào từng cấu phần quan trọng, cách thiết kế và implement các cấu phần này và một số kinh nghiệm cá nhân của mình, bắt đầu với hệ thống Identity.
Về cơ bản, hệ thống Identity sẽ làm 2 việc: Authentication và Authorization
Authentication: đây là quá trình xác minh danh tính của một người dùng hoặc một thực thể trong hệ thống. Nó trả lời câu hỏi: "Bạn có đúng là người mà bạn nói mình là không?"
Authorization: là quá trình xác định quyền hạn mà một danh tính đã được xác thực có thể thực hiện. Nó trả lời câu hỏi: "User được phép làm những gì sau khi đã được xác thực?"
Google Cloud (và các cloud provider khác) cung cấp dịch vụ IAM để quản lý Identity. Tuy nhiên, một điểm cần lưu ý, IAM trên GCP được sử dụng để phân quyền truy cập là chính, tức là thực hiện Authorization. Để thực hiện Authentication, ta sẽ phải sử dụng thêm dịch vụ Cloud Identity.
1. Cloud Identity và Authentication
1.1 Cloud Identity
Cloud Identity là 1 lớp SaaS đứng trước IAM chịu trách nhiệm authenticate các identity muốn vào Google Cloud. Cloud Identity cũng được sử dụng để provision user mới, tạo và gán user vào các group, và config các request về security như MFA, SSO, Device Management,… Mặc dù được tích hợp với Google Cloud, nhưng portal của Cloud Identity không nằm chung với portal của GCP, mà nằm ở admin.google.com (do Cloud Identity thực chất cũng là 1 product của Google Workspace).
Doanh nghiệp muốn sử dụng Google Cloud sẽ phải đăng ký tạo Cloud Identity Organization với domain của mình. Quá trình này khá đơn giản, chỉ cần yêu cầu có quyền chỉnh sửa DNS Record của domain để thực hiện verify theo hướng dẫn tại đây Lưu ý là Cloud Identity mặc định sẽ cung cấp tối đa 50 license free cho organization (có thể request tăng thêm, cái này nên đi qua partner thì dễ xin hơn). Doanh nghiệp cũng ko bắt buộc phải sử dụng Google Workspace để dùng Cloud Identity, nên với nhu cầu cơ bản, Cloud Identity sẽ free.
1.2 Authentication
Với hệ thống Identity cho Landing Zone, có 2 phương án authentication cân nhắc:
Dùng luôn Google Authentication: với phương án này, Cloud Identity sẽ đóng vai trò là Identity Provider (IdP), user sẽ sử dụng Google Account được cấp bởi Cloud Identity để đăng nhập vào Google Cloud và các dịch vụ Google khác, tương tự như dùng Gmail. Phương án này sẽ phù hợp cho 3 trường hợp sau:
Doanh nghiệp đã và đang sử dụng Google Workspace
Doanh nghiệp không có Identity Provider (IdP) nào khác ngoài Cloud Identity
Doanh nghiệp đã có IdP nhưng muốn quick start sử dụng Google Cloud cho một vài user và sẽ cân nhắc kết nối sau này
Với phương án này, chỉ cần thiết lập Cloud Identity và quản lý user trên portal là được.
Liên kết (federating) với IdP hiện có: trong trường hợp doanh nghiệp đã có IdP (Active Directory, Azure AD, ForgeRock, Okta, or Ping Identity) và muốn nhân sự sử dụng account sẵn có để dùng Google Serivce, Cloud Identity cho phép cấu hình liên kết tới IdP của doanh nghiệp và cho phép Single-sign-on bằng account của IdP. Đây là phương án thường dùng cho Enterprise, do thường doanh nghiệp vốn đã sử dụng Office365 cho nhân sự, nên việc quản lý identity tập trung tại 1 nơi sẽ giảm được các vấn đề về management và security.
Federation giữa IdP và Cloud Identity
Khi triển khai Cloud Identity, sẽ có 1 số lưu ý sau:
Consumer Account: nếu doanh nghiệp chưa từng dùng Cloud Identity hoặc Google Workspace, khả năng cao là đã có nhân sự sử dụng email công ty để tạo Google Account. Các account này được gọi là consumer account, người tạo có toàn quyền quản lý account này chứ không phải doanh nghiệp, và có thể chứa data cá nhân hoặc của doanh nghiệp đó. Vì vậy, best practice là nên hợp các account này (consolidate) vào organzation của công ty khi cấu hình Cloud Identity.
Super Admin Account: đây là account có quyền lớn nhất, vì vậy best practice là không nên sử dụng account này cho các task thông thường hàng ngày, mà chỉ nên dùng khi thực sự cần thiết. Google có một checklist các best practice để bảo vệ super admin account tại đây. Doanh nghiệp cũng có thể apply các quy trình bảo vệ account nếu có, ví dụ như thêm các break glass account đóng phong bì cất két sắt, chỉ lấy ra sử dụng trong trường hợp khẩn cấp.
Super Admin mặc định sẽ bypass SSO: nếu doanh nghiệp sử dụng phương án 2 để federate IdP, user đóng vai trò là Super Admin tại Cloud Identity sẽ không thể sử dụng được SSO ngược về IdP đó. Đây là exception của Google, để đảm bảo rằng nếu local IdP gặp vấn đề, super admin vẫn có thể đăng nhập vào Cloud Identity bình thường. Vậy nên, trong trường hợp đã setup xong federation mà account lúc đăng nhập không bị redirect về IdP để SSO, hãy kiểm tra xem account đó có phải là Super Admin không.
Với phương án 2, Google có tài liệu hướng dẫn setup federation với các IdP phổ biến, mọi người có thể follow thêm ở đây
1.3 Quản lý user
Nếu doanh nghiệp sử dụng Google Workspace, thì việc quản lý user sẽ diễn ra ở portal Cloud Identity, bao gồm các task như tạo user, group, phân quyền dịch vụ (Google Service, không phải Google Cloud), và các thiết lập khác về security. Trong trường hợp federate với IdP, user và group sẽ được đồng bộ từ IdP lên Cloud Identity, và chúng ta cũng sẽ chọn được user nào và group nào sẽ được đồng bộ lên. Lưu ý: Password sẽ không được đồng bộ. Sau khi setup xong SSO, khi user muốn truy cập vào Google Cloud sẽ được redirect về IdP để login với credential được cấp, đảm bảo rằng việc quản lý user sẽ diễn ra tại 1 nơi duy nhất là IdP.
Đối với 1 doanh nghiệp, có thể có nhiều nhân sự và phòng ban có nhu cầu truy cập vào resource trên GCP. Để tránh chồng chéo chức năng và dễ dàng quản lý, best practice là tổ chức user thành các group, và gán quyền theo chức năng cho group đó.
2. Cloud IAM và Authorization
2.1 IAM Role và Policy
Chúng ta có thể quy định quyền truy cập dựa vào IAM Policy. IAM Policy sẽ quy định “Ai có quyền gì tại resource nào” trên Google Cloud, kèm danh sách các permission cho account đó. Các permission là đơn vị phân quyền thấp nhất, và thường sẽ được gom nhóm lại thành các IAM role để dễ sử dụng.
Có 3 loại IAM role chính:
Basic Role: sẽ bao gồm 4 quyền: Browser, Viewer, Editor và Owner: Đây là các quyền có scope rất lớn bao trùm gần như toàn bộ các dịch vụ trên Google Cloud, với phạm vi khác nhau. Ví dụ, Owner tương đương với quyền Admin, có thể kiểm soát toàn bộ tài nguyên có trong project. Editor cũng có scope tương tự như Owner, nhưng không bao gồm các quyền quản trị như IAM. Viewer và Brower là các quyền read-only, tuy nhiên Browser chỉ cho phép nhìn thấy project chứ không nhìn thấy được các resource có trong project đó. Do 4 role này có scope quá rộng, best practice là không nên sử dụng Basic role, mà dùng các role khác có phạm vi nhỏ hơn.
Predefined Role: đây là các role được Google tạo sẵn cho các service có trên GCP và chỉ có permission trong các service đó. Ví dụ với dịch vụ Cloud Storage, Google đã định nghĩa sẵn một số role bao gồm Storage Admin, Storage Bucket Viewer, Object Creator,… các role này đã có sẵn các permission cần thiết để sử dụng dịch vụ. Predefined Role sẽ có scope nhỏ hơn so với Basic Role, an toàn hơn để sử dụng, thích hợp để gán quyền thông thường ở level service.
Một số predefined role hay được sử dụng Custom Role: ngoài việc dùng những role có sẵn, ta cũng có thể tự tạo các custom role theo nhu cầu, bằng cách thêm từng permission cần thiết vào role. Đây là cách phức tạp nhất để gán quyền cho role, phù hợp dùng trong những trường hợp muốn kiểm soát permission sâu.
Mặc định, các role trên khi gán cho account thì sẽ cấp quyền trên toàn bộ tài nguyên của dịch vụ đó. Để giới hạn tài nguyên được cấp quyền, ta có thể dùng IAM Condition, cho phép chọn tài nguyên để gán quyền dựa trên attribute của tài nguyên đó. Ví dụ, để chọn Cloud Storage bucket với prefix nhất định, thêm condition theo mẫu sau:
resource.name.startsWith("projects/_/buckets/myco-team-a-")
Note: IAM Condition sử dụng format Common Expression Language (CEL) để định nghĩa.
Để dễ tìm role và permission cụ thể, sử dụng tool IAM roles and permissions index.
2.2 Service Account
Service Account là một loại account đặc biệt được gán cho application và service trên GCP. Service account không hoạt động theo kiểu login bằng browser thông thường mà được authenticate bằng private/public key, và được Google quản lý. Một tài nguyên trên GCP khi muốn có quyền kết nối tới service hoặc Google API sẽ phải cần được gán serivce account và được cấp quyền như bình thường thông qua IAM role.
Có 3 loại service account, bao gồm:
User-managed: người dùng có thể tạo service account, phân quyền theo yêu cầu và gán vào tài nguyên cụ thể để cấp quyền cho tài nguyên đó.
Service default: một số dịch vụ trên GCP sẽ tự tạo default service account khi mới được enable. Ví dụ, khi enable Compute Engine API, Google sẽ tạo default service account, và mặc định sẽ được gán vào VM nếu không gán user-managed service account. Default service account mặc định sẽ được gán quyền Editor
Service Agents: đây là loại service account đặc biệt chỉ sử dụng trong một số trường hợp đặc biệt, khi dịch vụ của Google Cloud cần quyền truy cập resource có trong project, thì Google sẽ tạo ra service agent để tự cấp quyền cho mình. Bản chất service agent không thuộc project của người dùng, mà do Google quản lý, nên mặc định, chúng ta sẽ không thấy được account này trên portal IAM, mà phải chọn option như dưới để thấy.
Có một check box nhỏ ở portal IAM để xem các service agent
3. Best practices
3.1 Bảo vệ account
Bảo vệ account là nền tảng của mọi chiến lược bảo mật. Dưới đây là các checklist quan trọng để cấu hình bảo vệ account:
Với các Admin account: https://support.google.com/a/answer/9011373
Với các account khác: Tham khảo check list của Enterprise Foundation Blueprint
3.2 Cloud IAM best practices
Principle of least privilege: cơ bản nhất vẫn là kiểm soát quyền gán cho các account, chỉ nên gán quyền tối thiểu, không nên gán các quyền vượt quá scope yêu cầu cho từng account, và không nên dùng Basic Role.
Nên phân quyền cho Group, tránh gán quyền cho user riêng lẻ dẫn đến khó quản lý user. Danh sách một số group thường dùng trên GCP tham khảo tại đây.
Khi thực hiện thay đổi role (thêm, sửa xoá), có thể sử dụng thêm các intelligence tools sau để debug IAM policy.
Các IAM intelligence tools Sử dụng Audit Log để monitor các thay đổi với IAM Policy (sẽ đề cập rõ hơn tại phần về Logging và Monitoring)
Google cũng cung cấp checklist để sử dụng IAM an toàn và bảo mật hơn, tham khảo thêm tại đây.
3.2 Service account
Mặc dù service account là một thành phần cực kì quan trọng để cấp quyền cho service trên Google Cloud, service account đồng thời cũng là nguyên nhân số 1 khiến account Google Cloud bị hack. Rất nhiều trường hợp các doanh nghiệp bị lộ service account key khiến cho hacker chiếm được quyền truy cập vào GCP account, dẫn đến rủi ro bảo mật và tăng đột biến chi phí sử dụng GCP. Dưới đây là một số best practices:
Tránh sử dụng default Compute Engine service account: như đã đề cập ở trên, default Compute Engine service account sẽ được tạo với quyền Editor khi enable dịch vụ Compute Engine và mặc định sẽ được gán vào VM mới. Do Editor là Basic Role có quyền rất lớn, vì vậy chúng ta không nên dùng service account này mà nên tạo service account khác và limit role lại. Ngoài ra, tốt nhất là nên disable default service account này (không nên xoá).
Trong mọi trường hợp, nếu được, TUYỆT ĐỐI KHÔNG SỬ DỤNG SERVICE ACCOUNT KEY. Đa số các trường hợp bị lộ key là do user push nhầm key lên các public repository, và rất nhiều trong số đó là default Compute Engine service account key với quyền Editor. Có một số cách để sử dụng service account mà không cần key như Identity Federation, hoặc nếu dùng thẳng trên GCP thì không cần tạo key cho service account và để Google xử lý backend phần identity này. Để quyết định xem có nên cần tạo service account không, follow theo diagram sau:
Một số Organization Policy (sẽ giải thích kỹ hơn ở phần sau) có thể giúp hạn chế rủi ro của việc sử dụng service account (cấm tạo key, revoke key nếu phát hiện bị push lên public repo,..) và nên được bật khi cấu hình Landing Zone.
Đây là một số lưu ý thường gặp khi sử dụng service account. Danh sách các best practices khác cho service account có thể tham khảo tại đây.
Trên đây là một số note của mình về thiết lập cấu phần Identity cho Landing Zone. Mặc dù đóng vai trò rất quan trọng, nhưng effort cho phần này không quá nhiều, do chúng ta sử dụng SaaS để cấu hình, các option đã có sẵn hoặc chỉ cần bật lên. Miễn sao chúng ta follow theo các checklist và best practice khi thiết lập và vận hành, thì việc sử dụng cấu phần Identity sẽ tương đối đơn giản.
Trong phần tiếp theo, chúng ta sẽ tìm hiểu các cách tổ chức tài nguyên trên Google Cloud, và cùng phân tích các phương án thiết kế mô hình phân cấp tài nguyên cho một Organization.