Tóm tắt lại
Trong blog trước, chúng tôi đã giới thiệu những điều cơ bản về quyền tệp OneFS, bao gồm:
1. Quyền tệp OneFS chỉ ở một trong các trạng thái sau:
- Bit chế độ POSIX – có thẩm quyền với ACL tổng hợp
- OneFS ACL – có thẩm quyền với các bit chế độ POSIX gần đúng
2. Bất kể trạng thái cấp phép tệp OneFS là gì, danh tính trên đĩa cho tệp luôn là UID, GID hoặc SID. Tên của người dùng hoặc nhóm chỉ để hiển thị.
3. Khi OneFS nhận được yêu cầu truy cập của người dùng, nó sẽ tạo mã thông báo truy cập cho người dùng và so sánh mã thông báo đó với quyền tệp dựa trên UID/GID/SID.
Do đó, trong blog này, chúng tôi sẽ giải thích UID/GID/SID là gì và sẽ giải thích mã thông báo truy cập OneFS là gì. Bây giờ, chúng ta hãy bắt đầu bằng cách xem xét UID/GID/SID.
UID/GID và SID
Trong cuộc sống hàng ngày, chúng ta thường quen thuộc với tên người dùng hoặc tên nhóm, đại diện cho một người dùng hoặc một nhóm. Trong hệ thống NAS, chúng ta sử dụng UID, GID và SID để xác định người dùng hoặc nhóm, sau đó hệ thống NAS sẽ phân giải UID, GID và SID thành tên người dùng hoặc tên nhóm có liên quan.
UID/GID thường được sử dụng trong môi trường UNIX để xác định người dùng/nhóm có số nguyên dương được chỉ định. UID/GID thường được cung cấp bởi hệ điều hành cục bộ và máy chủ LDAP.
SID thường được sử dụng trong môi trường Windows để xác định người dùng/nhóm. SID thường được cung cấp bởi hệ điều hành cục bộ và Active Directory (AD). SID được viết theo định dạng:
(SID)-(mức độ sửa đổi)-(quyền hạn định danh)-(quyền hạn phụ1)-(quyền hạn phụ2)-(v.v.)
Ví dụ:
S-1-5-21-1004336348-1177238915-682003330-512
Để biết thêm thông tin về SID, hãy xem bài viết của Microsoft: Mã định danh bảo mật là gì ?.
Mã thông báo truy cập OneFS
Trong OneFS, thông tin về người dùng và nhóm được quản lý và lưu trữ trong các nhà cung cấp xác thực khác nhau, bao gồm thông tin UID/GID và SID, và thông tin thành viên nhóm người dùng. OneFS có thể thêm nhiều loại nhà cung cấp xác thực, bao gồm:
- Thư mục hoạt động (AD)
- Máy chủ Giao thức truy cập thư mục nhẹ (LDAP)
- NIS
- Nhà cung cấp tập tin
- Nhà cung cấp địa phương
OneFS truy xuất danh tính của người dùng (UID/GID/SID) và tư cách thành viên nhóm từ các nhà cung cấp xác thực nêu trên. Giả sử chúng ta có một người dùng tên là Joe, OneFS cố gắng giải quyết UID/GID và tư cách thành viên nhóm của Joe từ LDAP, NIS, nhà cung cấp tệp và nhà cung cấp cục bộ. Trong khi đó, nó cũng cố gắng giải quyết SID và tư cách thành viên nhóm của Joe từ AD, nhà cung cấp tệp hoặc nhà cung cấp cục bộ.
- Nếu không tìm thấy UID/GID hoặc SID trong bất kỳ nhà cung cấp xác thực nào, thì người dùng không tồn tại. Quyền truy cập của người dùng có thể bị từ chối hoặc được ánh xạ tới người dùng ‘không ai’, tùy thuộc vào giao thức của bạn.
- Nếu chỉ tìm thấy UID/GID hoặc chỉ tìm thấy SID, OneFS sẽ tạo một UID hoặc SID giả cho người dùng.
Không phải lúc nào OneFS cũng cần giải quyết người dùng từ tên người dùng thành UID/GID/SID. Cũng có thể OneFS cần giải quyết người dùng theo chiều ngược lại: nghĩa là giải quyết UID thành tên người dùng có liên quan. Điều này thường xảy ra khi sử dụng NFSv3. Khi OneFS lấy được tất cả thông tin UID/GID/SID cho người dùng, nó sẽ duy trì mối quan hệ danh tính trong cơ sở dữ liệu cục bộ, ghi lại UID <--> SID và ánh xạ GID <-->SID, còn được gọi là chức năng ánh xạ ID trong OneFS.
Bây giờ, bạn đã có ý tưởng tổng quan về cách OneFS duy trì thông tin UID/GID/SID quan trọng và cách truy xuất thông tin này khi cần.
Tiếp theo, hãy xem OneFS có thể xác định xem các tên người dùng khác nhau trong các loại xác thực khác nhau có thực sự là cùng một người dùng thực hay không. Ví dụ: làm sao chúng ta có thể biết Joe trong AD và joe_f trong LDAP có phải là cùng một người hay không? Nếu chúng giống nhau, OneFS cần đảm bảo rằng chúng có cùng quyền truy cập vào cùng một tệp, ngay cả với các giao thức khác nhau.
Đó là phép thuật của chức năng ánh xạ người dùng OneFS . Quy tắc ánh xạ người dùng mặc định ánh xạ những người dùng có cùng tên người dùng trong các nhà cung cấp xác thực khác nhau. Ví dụ: Joe trong AD và Joe trong LDAP sẽ được coi là cùng một người dùng. Bạn phải tạo các quy tắc ánh xạ người dùng nếu người dùng thực có tên khác nhau trong các nhà cung cấp xác thực khác nhau. Quy tắc ánh xạ người dùng có thể có các toán tử khác nhau để cung cấp khả năng quản lý linh hoạt hơn giữa các tên người dùng khác nhau trong các nhà cung cấp xác thực khác nhau. Các toán tử có thể là Thêm, Chèn, Thay thế, Xóa Nhóm, Tham gia. Xem các toán tử ánh xạ người dùng OneFS để biết thêm chi tiết. Chúng ta chỉ cần nhớ rằng ánh xạ người dùng chỉ là một hàm để xác định xem thông tin người dùng trong nhà cung cấp xác thực có nên được sử dụng khi tạo mã thông báo truy cập hay không.
Mặc dù dễ nhầm lẫn giữa ánh xạ người dùng với ánh xạ ID, ánh xạ người dùng là quá trình xác định người dùng trên các nhà cung cấp xác thực nhằm mục đích tạo mã thông báo. Sau khi mã thông báo được tạo, các ánh xạ SID<-->UID được đặt trong cơ sở dữ liệu ánh xạ ID.
Cuối cùng, OneFS phải chọn một danh tính có thẩm quyền (tức là Danh tính trên đĩa) từ UID/GID/SID được thu thập/tạo cho người dùng, danh tính này sẽ được lưu trữ trên đĩa và được sử dụng khi tệp được tạo hoặc khi quyền sở hữu tệp thay đổi, ảnh hưởng đến quyền đối với tệp.
Trong môi trường giao thức đơn, việc xác định On-Disk Identity rất đơn giản vì Windows sử dụng SID và Linux sử dụng UID. Tuy nhiên, trong môi trường đa giao thức, chỉ có một danh tính được lưu trữ và thách thức là xác định danh tính nào được lưu trữ. Theo mặc định, chính sách được cấu hình cho danh tính trên đĩa là chế độ Native. Chế độ Native là tùy chọn tốt nhất cho hầu hết các môi trường. OneFS chọn giá trị thực giữa SID và UID/GID. Nếu cả SID và UID/GID đều là giá trị thực, OneFS sẽ chọn UID/GID. Xin lưu ý rằng loạt blog này dựa trên cài đặt chính sách mặc định.
Bây giờ bạn đã có hiểu biết chung về ánh xạ người dùng, ánh xạ ID và danh tính trên đĩa. Đây là những khái niệm chính khi hiểu mã thông báo truy cập của người dùng và thực hiện khắc phục sự cố. Cuối cùng, hãy xem mã thông báo truy cập chứa những gì.
Bạn có thể xem mã thông báo truy cập của người dùng bằng cách sử dụng lệnh isi auth mapping token <username> trong OneFS. Sau đây là ví dụ về mã thông báo truy cập của Joe:
vonefs-aima-1# mã thông báo ánh xạ xác thực isi Joe Người sử dụng Tên: Joe Mã số nhận dạng: 2001 Mã số thuế: S-1-5-21-1137111906-3057660394-507681705-1002 Trên đĩa: 2001 Số hiệu: 1 Khu vực: Hệ thống Quyền lợi: - Nhóm chính Tên: Chợ Số hiệu: 2003 Mã số thuế: S-1-5-21-1137111906-3057660394-507681705-1006 Trên đĩa: 2003 Danh tính bổ sung Tên: Người dùng đã xác thực SID: S-1-5-11 Dưới đây
Từ kết quả ở trên, chúng ta có thể thấy rằng mã thông báo truy cập chứa thông tin sau:
- Tên người dùng, UID, SID và danh tính cuối cùng trên đĩa của người dùng
- ID và tên vùng truy cập
- Quyền OneFS RBAC
- Tên nhóm chính, GID, SID và danh tính cuối cùng trên đĩa
- Tên nhóm bổ sung, GID hoặc SID.
Tuy nhiên, hãy nhớ rằng chúng ta có một tệp được Joe tạo và sở hữu trong blog trước? Sau đây là các quyền đối với tệp:
vonefs-aima-1# ls -le acl-file.txt -rwxrwxr-x + 1 Joe Market 69 28 tháng 5 01:08 acl-file.txt CHỦ SỞ HỮU: người dùng:Joe NHÓM: nhóm:Thị trường 0: người dùng:Joe cho phép file_gen_all 1: nhóm:Market cho phép file_gen_read,file_gen_execute 2: người dùng:Bob cho phép file_gen_all 3: mọi người cho phép file_gen_read, file_gen_execute
Lệnh ls -le ở đây chỉ hiển thị tên người dùng. Và chúng tôi đã nhấn mạnh rằng danh tính trên đĩa luôn là UID/GID hoặc SID, vì vậy hãy sử dụng lệnh ls -len để hiển thị danh tính trên đĩa. Trong đầu ra sau, chúng ta thấy rằng danh tính trên đĩa của Joe là UID 2001 và GID 2003 của anh ấy. Khi Joe muốn truy cập tệp, OneFS so sánh mã thông báo truy cập của Joe với các quyền tệp bên dưới, thấy rằng UID của Joe là 2001 trong mã thông báo của anh ấy và cấp cho anh ấy quyền truy cập vào tệp.
vonefs-aima-1# ls -len acl-file.txt -rwxrwxr-x + 1 2001 2003 69 28 tháng 5 01:08 acl-file.txt CHỦ SỞ HỮU: người dùng:2001 NHÓM: nhóm:2003 0: người dùng:2001 cho phép file_gen_all 1: nhóm:2003 cho phép file_gen_read,file_gen_execute 2: người dùng:2002 cho phép file_gen_all 3: SID:S-1-1-0 cho phép file_gen_read,file_gen_execute
Joe ở trên là người dùng cục bộ OneFS từ một nhà cung cấp cục bộ. Tiếp theo, chúng ta sẽ xem mã thông báo truy cập trông như thế nào nếu SID của người dùng là từ AD và UID/GID là từ LDAP.
Giả sử người dùng John có một tài khoản tên là John_AD trong AD và cũng có một tài khoản tên là John_LDAP trong máy chủ LDAP. Điều này có nghĩa là OneFS phải đảm bảo rằng hai tên người dùng có quyền truy cập nhất quán trên một tệp. Để đạt được điều đó, chúng ta cần tạo một quy tắc ánh xạ người dùng để kết hợp chúng lại với nhau, để mã thông báo truy cập cuối cùng sẽ chứa thông tin SID trong AD và thông tin UID/GID trong LDAP. Mã thông báo truy cập cho John_AD trông như thế này:
vonefs-aima-1# isi auth ánh xạ token vlab\\John_AD Người sử dụng Tên: VLAB\john_ad Mã số nhận dạng: 1000019 Mã số thuế: S-1-5-21-2529895029-2434557131-462378659-1110 Trên đĩa: S-1-5-21-2529895029-2434557131-462378659-1110 Số hiệu: 1 Khu vực: Hệ thống Quyền lợi: - Nhóm chính Tên: Người dùng VLAB\domain Mã số: 1000041 Mã số thuế: S-1-5-21-2529895029-2434557131-462378659-513 Trên đĩa: S-1-5-21-2529895029-2434557131-462378659-513 Danh tính bổ sung Tên: Người dùng Mã số: 1545 Mã số thuế: S-1-5-32-545 Tên: Người dùng đã xác thực Mã số thuế: S-1-5-11 Tên: John_LDAP UID: 19421 Mã số: S-1-22-1-19421 Tên: ldap_users Mã số: 32084 Mã số thuế: S-1-22-2-32084
Giả sử rằng một tệp do John_LDAP sở hữu và chỉ có thể truy cập được có các quyền tệp được hiển thị trong đầu ra sau. Vì John_AD và John_LDAP được liên kết với nhau bằng quy tắc ánh xạ người dùng, nên danh tính John_LDAP (UID) cũng nằm trong mã thông báo truy cập John_AD, do đó John_AD cũng có thể truy cập tệp.
vonefs-aima-1# ls -le john_ldap.txt -rwx------ 1 John_LDAP ldap_users 19 tháng 6 năm 15 07:36 john_ldap.txt CHỦ SỞ HỮU: người dùng:John_LDAP NHÓM: nhóm: ldap_users ACL TỔNG HỢP 0: người dùng: John_LDAP cho phép file_gen_read, file_gen_write, file_gen_execute, std_write_dac 1: nhóm: ldap_users cho phép std_read_dac, std_synchronize, file_read_attr
Bây giờ bạn đã hiểu về mã thông báo truy cập OneFS và cách chúng được sử dụng để xác định thao tác được người dùng ủy quyền trên dữ liệu thông qua việc kiểm tra quyền tệp.

Bài viết mới cập nhật
Dell Storage Engines: Tăng tốc suy luận AI với PowerScale và ObjectScale
Giải pháp chuyển tải bộ nhớ đệm KV của Dell cho ...
Bảo vệ Nhà máy AI
Áp dụng phương pháp tiếp cận kiến trúc để bảo mật ...
Tiến lên mạnh mẽ với Dell PowerMax: Vượt mặt Hitachi VSP 5000
Dell PowerMax mang lại khả năng phục hồi, hiệu suất và ...
Đẩy nhanh đổi mới AI: Sức mạnh của quyền truy cập mở
Từ các mô hình tiên tiến đến các ứng dụng cấp ...