Cách tự động điều phối quyền truy cập trong nhóm AWS S3 trong 3 bước đơn giản
Nhiều năm trước, khi các máy chủ Unix tại chỗ với hệ thống tệp lớn là một vấn đề, các công ty đã xây dựng các quy tắc và chiến lược quản lý thư mục mở rộng để 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 một tổ chức phục vụ các nhóm người dùng khác nhau với các sở thích, giới hạn mức độ bảo mật hoặc định nghĩa nội dung hoàn toàn khác biệt. Trong trường hợp của các tổ chức toàn cầu, điều này thậm chí có thể có nghĩa là phân tách nội dung dựa trên vị trí, về cơ bản, giữa những người dùng thuộc các quốc gia khác nhau.
Các ví dụ điển hình 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 tiếp cận được với nhiều đối tượng
- nội dung lập pháp dành riêng cho quốc gia không thể xem hoặc truy cập từ bên trong khu vực khác
- nội dung liên quan đến dự án trong đó “dữ liệu lãnh đạo” chỉ được cung cấp cho 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ó một số loại nhu cầu sắp xếp quyền truy cập vào tệp và dữ liệu giữa tất cả người dùng mà nền tảng cung 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 nhiệm vụ thường xuyên. Quản trị viên của hệ thống tệp chỉ cần thiết lập một số quy tắc, sử dụng một công cụ tùy chọn, sau đó mọi người được ánh xạ vào các nhóm người dùng và các nhóm người dùng được ánh xạ vào danh sách các thư mục hoặc điểm gắn kết mà họ có thể truy cập. Đồng thời, cấp độ truy cập được xác định là quyền truy cập chỉ đọc hoặc đọc & ghi.
Giờ đây, khi xem xét các nền tảng đám mây AWS, rõ ràng mọi người sẽ có các yêu cầu tương tự đối với các hạn chế truy cập nội dung. Tuy nhiên, bây giờ, giải pháp cho vấn đề này phải khác. Các tệp không còn kháng cự trên các máy chủ Unix mà trên đám mây (và có khả năng truy cập không chỉ đối với toàn bộ tổ chức mà thậm chí cả thế giới) và nội dung không được lưu trữ trong các thư mục mà trong các bộ chứa S3.
Dưới đây mô tả là một thay thế để tiếp cận vấn đề này. Nó được xây dựng dựa trên kinh nghiệm thực tế mà tôi có được khi thiết kế các giải pháp như vậy cho một dự án cụ thể.
Cách tiếp cận thủ công đơn giản nhưng rộng rãi
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 và dễ hiểu:
- Tạo một nhóm mới cho từng nhóm người riêng biệt.
- Gán quyền truy cập cho bộ chứa để chỉ nhóm cụ thể này mới có thể truy cập vào bộ chứa S3.
Điều này chắc chắn là có thể nếu yêu cầu là đi kèm với một giải pháp rất đơn giản và nhanh chóng. Tuy nhiên, có một số giới hạn cần lưu ý.
Theo mặc định, chỉ có thể tạo tối đa 100 bộ chứa S3 trong một tài khoản AWS. Bạn có thể mở rộng giới hạn này lên 1000 bằng cách gửi yêu cầu tăng giới hạn dịch vụ cho phiếu AWS. Nếu những giới hạn đó không phải là điều mà trường hợp triển khai cụ thể của bạn sẽ lo lắng, thì bạn có thể để mỗi người dùng miền riêng biệt của mình vận hành trên một nhóm S3 riêng biệt và gọi nó là một ngày.
Các vấn đề có thể phát sinh nếu có một số nhóm người có trách nhiệm liên chức năng hoặc đơn giản là một số người cần truy cập vào nội dung của nhiều miề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 đã chia sẻ các dịch vụ phục vụ các nhóm phát triển khác nhau.
- Người dùng báo cáo yêu cầu xây dựng phân tích bảng điều khiển trên các quốc gia khác nhau trong cùng một khu vực.
Như bạn có thể tưởng tượng, danh sách này lại có thể tăng lên nhiều như bạn có thể tưởng tượng và nhu cầu của các tổ chức có thể tạo ra tất cả các loại trường hợp sử dụng.
Danh sách này càng phức tạp thì việc sắp xếp 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 đối với các nhóm S3 khác nhau trong tổ chức. Sẽ có các công cụ bổ sung cần thiết và thậm chí có thể một tài nguyên chuyên dụng (quản trị viên) sẽ cần duy trì danh sách quyền truy cập và cập nhật chúng bất cứ khi nào có bất kỳ thay đổi nào được yêu cầu (điều này sẽ rất thường xuyên, đặc biệt nếu tổ chức lớn).
Vậy thì, làm thế nào để đạt được điều tương tự theo cách có tổ chức và tự động hơn?
Nếu cách tiếp cận nhóm trên mỗi miền không hoạt động, bất kỳ giải pháp nào khác sẽ kết thúc bằng các nhóm được chia sẻ cho nhiều nhóm người dùng hơn. Trong những trường hợp như vậy, cần phải xây dựng toàn bộ logic gán quyền truy cập trong một số khu vực dễ thay đổi hoặc cập nhật động.
Một trong những cách để đạt được điều đó là sử dụng Thẻ trên bộ chứa S3. Các thẻ được khuyến nghị sử dụng trong mọi trường hợp (nếu không có mục đích gì khác ngoài việc cho phép phân loại thanh toán dễ dàng hơn). Tuy nhiên, thẻ có thể được thay đổi bất cứ lúc nào trong tương lai cho bất kỳ nhóm nào.
Nếu toàn bộ logic được xây dựng dựa trên thẻ bộ chứa và phần còn lại phía sau là cấu hình phụ thuộc vào giá trị thẻ, thì thuộc tính động được đảm bảo vì người ta có thể xác định lại mục đích của bộ chứa chỉ bằng cách cập nhật giá trị thẻ.
Những loại thẻ để sử dụng để làm cho công việc này?
Điều này phụ thuộc vào trường hợp sử dụng cụ thể của bạn. Ví dụ:
- Có thể cần phải tách các nhóm cho mỗi loại môi trường. Vì vậy, trong trường hợp đó, một trong các tên thẻ sẽ giống như “ENV” và có thể có các giá trị “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 đó, một thẻ khác sẽ là “QUỐC GIA” và đánh giá một số 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. Vì vậy, bạn tạo một thẻ có tên “USER_TYPE” và giá trị tương ứng.
- Một tùy chọn khác có thể là bạn muốn 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 yêu cầu sử dụng (để không tạo ra các thư mục lộn xộn của riêng họ và bị mất ở đó theo thời gian). Bạn có thể làm điều đó một lần nữa với các thẻ, nơi bạn có thể chỉ định một số thư mục đang hoạt động như: “data/import”, “data/processed”, “data/error”, v.v.
Lý tưởng nhất là bạn muốn xác định các thẻ để chúng có thể được kết hợp một cách hợp lý và làm cho chúng tạo thành một cấu trúc thư mục hoàn chỉnh trên bộ chứa.
Ví dụ: bạn có thể kết hợp các thẻ sau từ các ví dụ bên 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 mà họ dự kiến sẽ sử dụng:
- /
/ / /
Chỉ bằng cách thay đổi giá trị
Điều này sẽ cho phép sử dụng cùng một nhóm cho nhiều người dùng khác nhau. Các nhóm không hỗ trợ các thư mục một cách rõ ràng, nhưng chúng hỗ trợ các “nhãn”. Cuối cùng, các nhãn đó hoạt động giống như các thư mục con vì người dùng cần xem qua một loạt nhãn để truy cập dữ liệu của họ (giống như cách họ làm với các thư mục con).
Sau khi đã xác định các thẻ ở một số 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 các thẻ này.
Nếu các chính sách đang sử dụng tên thẻ, thì bạn đang tạo một thứ gọi là “chính sách động”. Về cơ bản, điều này có nghĩa là chính sách của bạn sẽ hoạt động khác đối với các nhóm có giá trị thẻ khác nhau mà chính sách đang đề cập đến trong biểu mẫu hoặc trình giữ chỗ.
Bước này rõ ràng liên quan đến một số mã hóa tùy chỉnh của các chính sách động, nhưng bạn có thể đơn giản hóa bước này bằng cách sử dụng công cụ biên tập chính sách Amazon AWS, công cụ này sẽ hướng dẫn bạn thực hiện quy trình.
Trong chính sách, bạn sẽ muốn mã hóa các quyền truy cập cụ thể sẽ được áp dụng cho bộ chứa và cấp độ truy cập của các quyền đó (đọc, ghi). Logic sẽ đọc các thẻ trên bộ chứa và sẽ xây dựng cấu trúc thư mục trên bộ chứa (tạo nhãn dựa trên thẻ). Dựa trên các giá trị cụ thể của cá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 dòng.
Điều thú vị về một chính sách động như vậy là bạn có thể chỉ tạo một chính sách động và sau đó gán chính sách động đó cho nhiều nhóm. Chính sách này sẽ hoạt động khác đối với các nhóm có giá trị thẻ khác nhau, nhưng chính sách này sẽ luôn phù hợp với mong đợi của bạn đối với nhóm có các giá trị thẻ như vậ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 đó kỳ vọng rằng mọi nhóm sẽ tuân theo một số cấu trúc mẫu đã được thỏa thuận trước và sẽ được người dùng của bạn sử dụng trong vòng toàn bộ tổ chức.
Tự động hóa việc giới thiệu các thực thể mới
Sau khi xác định các 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 rằng người dùng từ các nhóm khác nhau sẽ không truy cập nội dung (được lưu trữ trên cùng một nhóm) nằm trong cấu trúc thư mục mà họ không có tới gần.
Ngoài ra, đối với một số nhóm người dùng có quyền truy cập rộng hơn, sẽ dễ dàng tiếp cận dữ liệu vì tất cả dữ liệu sẽ được lưu trữ trên 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 đơn giản nhất có thể. Điều này dẫn đến một mã hóa tùy chỉnh khác, tuy nhiên, mã hóa này không cần quá phức tạp, giả sử quy trình giới thiệu của bạn có một số quy tắc rất rõ ràng có thể được gói gọn bằng logic thuật toán đơn giản, dễ hiểu (ít nhất bạn có thể chứng minh theo cách này rằng bạn quy trình có một số logic và nó không được thực hiện theo cách quá hỗn loạn).
Điều này có thể đơn giản như tạo một tập lệnh có thể thực thi được bằng lệnh AWS CLI với các tham số cần thiết để tích hợp thành công một thực thể mới vào nền tảng. Nó thậm chí có thể là một loạt các tập lệnh CLI, có thể thực thi được theo một số thứ tự cụ thể, chẳng hạn như:
- create_new_bucket(
, , , , ..) - create_new_tag(
, , ) - update_current_tag(
, , ) - create_user_group(
, , ) - vân vân.
Bạn sẽ có được điểm. 😃
Mẹo chuyên nghiệp 👨💻
Có một Mẹo chuyên nghiệp nếu bạn thích, mẹo này có thể dễ dàng áp dụng ngoài những mẹo trên.
Các chính sách động có thể được tận dụng không chỉ để gán quyền truy cập cho các vị trí thư mục mà còn để tự động gán quyền dịch vụ cho các nhóm và nhóm người dùng!
Tất cả những gì cần thiết là mở rộng danh sách các thẻ trên các nhóm và sau đó thêm quyền truy cập chính sách động để 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 số nhóm người dùng cũng cần quyền truy cập vào máy chủ cụm cơ sở dữ liệu cụ thể. Điều này chắc chắn có thể đạt được bằng các chính sách động tận dụng các tác vụ nhóm, hơn nữa nếu quyền truy cập vào các dịch vụ được thúc đẩy bởi cách tiếp cận dựa trên vai trò. Chỉ cần thêm vào mã chính sách động một phần sẽ xử lý các thẻ liên quan đến đặc tả cụm cơ sở dữ liệu và gán trực tiếp các đặc quyền truy cập chính sách cho cụm DB 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ẽ được thực thi chỉ bằng chính sách động duy nhất này. Hơn nữa, vì nó là động nên chính sách tương tự có thể được sử dụng lại để giới thiệu nhiều nhóm người dùng khác nhau (dự kiến tuân theo cùng một mẫu nhưng không nhất thiết phải giống các dịch vụ).
Bạn cũng có thể xem các Lệnh AWS S3 này để quản lý bộ chứa và dữ liệu.
