Nhiều năm trước, khi còn có các máy chủ Unix cục bộ với hệ thống tệp lớn, các công ty đã tạo ra các quy tắc và chính sách quản lý thư mục phức tạp để quản lý quyền truy cập vào các thư mục khác nhau cho những người khác nhau.
Thông thường, nền tảng của tổ chức phục vụ các nhóm người dùng khác nhau với các sở thích, hạn chế bảo mật hoặc định nghĩa nội dung hoàn toàn khác nhau. Đối với các tổ chức toàn cầu, điều này thậm chí có thể có nghĩa là tách nội dung dựa trên vị trí, về cơ bản là giữa những người dùng thuộc các quốc gia khác nhau.
Các ví dụ phổ biến khác có thể bao gồm:
- tách dữ liệu giữa các môi trường phát triển, thử nghiệm và sản xuất
- nội dung bán hàng không có sẵn cho nhiều đối tượng
- nội dung lập pháp theo quốc gia cụ thể không thể xem hoặc truy cập được từ khu vực khác
- nội dung liên quan đến các dự án trong đó “dữ liệu lãnh đạo” chỉ được chia sẻ với một nhóm người hạn chế, v.v.
Có một danh sách vô tận các ví dụ như vậy. Vấn đề là luôn có nhu cầu tổ chức quyền truy cập vào các tệp và dữ liệu giữa tất cả người dùng mà nền tảng cấp quyền truy cập.
Trong trường hợp các giải pháp tại chỗ, đây là một công việc thường xuyên. Quản trị viên hệ thống tệp chỉ cần thiết lập một số quy tắc, sử dụng công cụ lựa chọn, sau đó mọi người được ánh xạ tới các nhóm người dùng và các nhóm người dùng được ánh xạ tới danh sách các thư mục hoặc điểm gắn kết mà họ có quyền truy cập. Trong quá trình thực hiện, cấp độ truy cập được xác định là quyền truy cập chỉ đọc hoặc quyền truy cập đọc-ghi.
Nhìn vào nền tảng đám mây AWS hiện nay, rõ ràng mọi người sẽ có những yêu cầu tương tự về hạn chế truy cập nội dung. Tuy nhiên, giải pháp cho vấn đề này bây giờ hẳn đã khác. Các tệp không còn dựa trên máy chủ Unix mà trên đám mây (và có khả năng không chỉ có sẵn cho toàn bộ tổ chức mà thậm chí cả thế giới) và nội dung được lưu trữ không phải trong các thư mục mà trong các nhóm S3.
Một cách tiếp cận khác cho vấn đề này được mô tả dưới đây. Nó dựa trên kinh nghiệm thực tế mà tôi đã đạt được khi thiết kế các giải pháp như vậy cho một dự án cụ thể.
Một cách tiếp cận đơn giản nhưng rất thủ công
Một cách để giải quyết vấn đề này mà không cần tự động hóa là tương đối đơn giản:
- Tạo một nhóm mới cho từng nhóm người riêng biệt.
- Chỉ định quyền truy cập vào nhóm để chỉ nhóm cụ thể này mới có quyền truy cập vào nhóm S3.
Điều này chắc chắn có thể thực hiện được nếu cần một giải pháp rất đơn giản và nhanh chóng. Tuy nhiên, có một số hạn chế cần ghi nhớ.
Theo mặc định, có thể tạo tối đa 100 nhóm S3 trong một tài khoản AWS. Giới hạn này có thể được mở rộng lên 1000 bằng cách báo cáo mức tăng giới hạn dịch vụ đối với vé AWS. Nếu những hạn chế này không phải là điều mà trường hợp triển khai cụ thể của bạn quan tâm, thì bạn có thể cho phép mỗi người dùng trong miền riêng biệt chạy trên một bộ chứa S3 riêng biệt và tạm dừng hoạt động đó.
Các vấn đề có thể phát sinh nếu có những nhóm người chịu trách nhiệm liên chức năng hoặc chỉ một số người cần truy cập vào nội dung của nhiều miền hơn cùng một lúc. Ví dụ:
- Các nhà phân tích dữ liệu đánh giá nội dung dữ liệu cho một số khu vực, khu vực khác nhau, v.v.
- Nhóm thử nghiệm đã cung cấp dịch vụ để hỗ trợ các nhóm phát triển khác nhau.
- Báo cáo người dùng cần xây dựng bảng phân tích bảng điều khiển dựa trên các quốc gia khác nhau trong cùng khu vực.
Như bạn có thể tưởng tượng, danh sách này có thể phát triển trở lại nhiều như bạn có thể tưởng tượng và nhu cầu của tổ chức có thể tạo ra đủ loại trường hợp sử dụng.
Danh sách này càng phức tạp thì việc điều phối quyền truy cập càng phức tạp hơn để cấp cho tất cả các nhóm khác nhau các quyền truy cập khác nhau vào các nhóm S3 khác nhau trong tổ chức. Sẽ cần có các công cụ bổ sung và thậm chí có thể cần một nguồn lực chuyên dụng (quản trị viên) để duy trì danh sách các quyền truy cập và cập nhật chúng bất cứ khi nào cần có bất kỳ thay đổi nào (điều này sẽ rất thường xuyên, đặc biệt nếu tổ chức lớn).
Vậy làm thế nào để bạn đạt được điều tương tự theo cách có tổ chức và tự động hơn?
Nếu phương pháp “nhóm trên mỗi tên miền” không hiệu quả thì bất kỳ giải pháp nào khác cuối cùng cũng sẽ cung cấp các nhóm cho nhiều nhóm người dùng hơn. Trong những trường hợp như vậy, cần xây dựng toàn bộ logic cấp quyền truy cập trong một khu vực nhất định có thể dễ dàng thay đổi hoặc cập nhật linh hoạt.
Một cách để đạt được điều này là sử dụng thẻ trên nhóm S3. Nên sử dụng thẻ trong mọi trường hợp (ít nhất là để cho phép phân loại các khu định cư dễ dàng hơn). Tuy nhiên, thẻ có thể được thay đổi bất kỳ lúc nào trong tương lai cho bất kỳ nhóm nào.
Nếu tất cả logic được xây dựng xung quanh thẻ nhóm và phần còn lại phụ thuộc vào cấu hình giá trị thẻ thì thuộc tính động sẽ được cung cấp vì bạn có thể xác định lại mục đích của nhóm chỉ bằng cách cập nhật giá trị thẻ.
Những thẻ nào để sử dụng để làm cho nó hoạt động?
Nó phụ thuộc vào trường hợp sử dụng cụ thể. Ví dụ:
- Bạn có thể cần phải tách các nhóm theo loại môi trường. Trong trường hợp này, một trong các tên thẻ phải là “ENV” và chứa các giá trị có thể là “DEV”, “TEST”, “PROD”, v.v.
- Có thể bạn muốn tách nhóm dựa trên quốc gia. Trong trường hợp này, thẻ còn lại sẽ là “COUNTRY” và giá trị sẽ chứa tên quốc gia.
- Hoặc, bạn có thể muốn tách người dùng dựa trên bộ phận chức năng mà họ thuộc về, chẳng hạn như nhà phân tích kinh doanh, người dùng kho dữ liệu, nhà khoa học dữ liệu, v.v. Bạn tạo thẻ có tên “USER_TYPE” và một giá trị thích hợp.
- Một tùy chọn khác có thể là xác định rõ ràng cấu trúc thư mục cố định cho các nhóm người dùng cụ thể mà họ cần sử dụng (để họ không tạo ra các thư mục lộn xộn của riêng mình và bị lạc trong đó theo thời gian). Bạn có thể thực hiện lại việc này bằng các thẻ trong đó bạn có thể chỉ định một số thư mục hoạt động như: “dữ liệu/nhập”, “dữ liệu/đã xử lý”, “dữ liệu/lỗi”, v.v.
Lý tưởng nhất là bạn nên xác định các thẻ để chúng có thể được kết hợp một cách hợp lý và tạo ra toàn bộ cấu trúc thư mục trong nhóm.
Ví dụ: bạn có thể kết hợp các thẻ sau từ các ví dụ trên để tạo cấu trúc thư mục dành riêng cho các loại người dùng khác nhau từ các quốc gia khác nhau với các thư mục nhập được xác định trước để họ sử dụng:
Chỉ cần thay đổi giá trị, bạn có thể xác định lại mục đích của thẻ (có được gán cho hệ sinh thái môi trường thử nghiệm, nhà phát triển, sản phẩm, v.v.) hay không.
Điều này sẽ cho phép nhiều người dùng khác nhau sử dụng cùng một khay. Các khay không hỗ trợ rõ ràng các thư mục nhưng chúng hỗ trợ “nhãn”. Các nhãn này cuối cùng hoạt động như các thư mục con vì người dùng phải duyệt qua một loạt nhãn để tiếp cận dữ liệu của họ (giống như với các thư mục con).
Sau khi các thẻ được xác định ở dạng có thể sử dụng được, bước tiếp theo là xây dựng các chính sách bộ chứa S3 sẽ sử dụng thẻ.
Nếu chính sách sử dụng tên thẻ, bạn sẽ tạo cái được gọi là “chính sách động”. Về cơ bản, điều này có nghĩa là chính sách sẽ hoạt động khác nhau đối với các nhóm có giá trị thẻ khác nhau mà chính sách đề cập đến trong biểu mẫu hoặc phần giữ chỗ.
Bước này rõ ràng liên quan đến mã hóa chính sách động tùy chỉnh, nhưng bạn có thể đơn giản hóa bước này bằng công cụ soạn thảo chính sách Amazon AWS để hướng dẫn bạn thực hiện quy trình.
Trong chính chính sách này, bạn sẽ muốn mã hóa cứng các quyền truy cập cụ thể sẽ được áp dụng cho nhóm và cấp độ truy cập của các quyền đó (đọc, ghi). Logic sẽ đọc các thẻ trên nhóm và xây dựng cấu trúc thư mục trên nhóm (tạo nhãn dựa trên các thẻ). Dựa trên các giá trị thẻ cụ thể, các thư mục con sẽ được tạo và các quyền truy cập bắt buộc sẽ được chỉ định dọc theo các dòng.
Ưu điểm của chính sách động như vậy là bạn chỉ có thể tạo một chính sách động và sau đó gán chính sách động tương tự cho nhiều nhóm. Quy tắc này sẽ hoạt động khác nhau đối với các nhóm có giá trị thẻ khác nhau nhưng sẽ luôn phù hợp với mong đợi của bạn về nhóm có các giá trị thẻ này.
Đây là một cách thực sự hiệu quả để quản lý việc gán quyền truy cập theo cách có tổ chức, tập trung cho một số lượng lớn các nhóm trong đó mỗi nhóm dự kiến sẽ tuân theo một số cấu trúc mẫu đã được thỏa thuận trước và được người dùng trong toàn bộ tổ chức sử dụng.
Tự động hóa việc giới thiệu các thực thể mới
Bằng cách xác định chính sách động và gán chúng cho các nhóm hiện có, người dùng có thể bắt đầu sử dụng cùng một nhóm mà không gặp rủi ro là người dùng từ các nhóm khác nhau sẽ không thể truy cập vào nội dung (được lưu trữ trong cùng một nhóm) nằm trong cấu trúc thư mục mà họ không có không có quyền truy cập.
Ngoài ra, một số nhóm người dùng có quyền truy cập rộng hơn sẽ dễ dàng truy cập dữ liệu vì tất cả họ sẽ được lưu trữ trong cùng một nhóm.
Bước cuối cùng là làm cho việc giới thiệu người dùng mới, nhóm mới và thậm chí cả thẻ mới trở nên dễ dàng nhất có thể. Điều này dẫn đến một số mã hóa tùy chỉnh khác, tuy nhiên, không quá phức tạp, giả sử quy trình triển khai của bạn có một số quy tắc rất rõ ràng có thể được gói gọn trong logic thuật toán đơn giản, đơn giản (ít nhất bạn có thể chứng minh bằng điều này rằng quy trình của bạn có một số logic và không được chạy theo cách quá hỗn loạn).
Việc này có thể đơn giản như việc tạo một tập lệnh thực thi bằng lệnh AWS CLI với các tham số cần thiết để triển khai thành công thực thể mới lên nền tảng. Nó thậm chí có thể là một loạt các tập lệnh CLI, thực thi theo một thứ tự cụ thể, như sau:
- create_new_bucket(,,,, ..)
- create_new_tag(,,)
- update_hiện có_tag(,,)
- create_user_group(,,
) - vân vân.
Bạn nhận được một điểm. 😃
Tư vấn chuyên nghiệp 👨💻
Nếu bạn muốn, có một Mẹo chuyên nghiệp có thể dễ dàng áp dụng cho những điều trên.
Chính sách động có thể được sử dụng không chỉ để gán quyền truy cập vào vị trí thư mục mà còn để tự động gán quyền dịch vụ cho nhóm và nhóm người dùng!
Chỉ cần mở rộng danh sách thẻ trên nhóm là đủ, sau đó thêm quyền truy cập động vào chính sách để sử dụng các dịch vụ cụ thể cho các nhóm người dùng cụ thể.
Ví dụ: có thể có một nhóm người dùng cũng cần quyền truy cập vào một máy chủ cụm cơ sở dữ liệu cụ thể. Không còn nghi ngờ gì nữa, điều này có thể đạt được bằng các chính sách động sử dụng công việc nhóm, thậm chí còn hơn thế nữa nếu quyền truy cập dịch vụ dựa trên cách tiếp cận dựa trên vai trò. Chỉ cần thêm một phần vào mã chính sách động của bạn để xử lý các thẻ đặc tả cụm cơ sở dữ liệu và gán quyền truy cập chính sách trực tiếp cho cụm cơ sở dữ liệu và nhóm người dùng cụ thể đó.
Bằng cách này, việc giới thiệu một nhóm người dùng mới sẽ chỉ có thể thực hiện được nhờ chính sách động này. Ngoài ra, do tính linh hoạt nên chính sách tương tự có thể được sử dụng lại để thu hút nhiều nhóm người dùng khác nhau (họ phải tuân theo cùng một khuôn mẫu nhưng không nhất thiết phải có cùng các dịch vụ).
Bạn cũng có thể xem các lệnh AWS S3 này để quản lý nhóm và dữ liệu.
