Nguyễn Văn Thanh

2.2. Nền tảng và động lực

Sự quan tâm mới xuất hiện trở lại đây đối với RBAC tập trung chủ yếu vào khả năng sử dụng RBAC ở cấp độ ứng dụng. Trong quá khứ và cả ngày nay, các ứng dụng đặc biệt đã được xây dựng với RBAC được mã hóa trong bản thân sự ứng dụng. Các hệ điều hành hiện có và các môi trường cung cấp rất ít khả năng sử dụng RBAC ở cấp độ ứng dụng. Khả năng này bây giờ bắt đầu xuất hiện trong các sản phẩm. Thách thức đặt ra là phải xác định được ứng dụng độc lập tiện lợi khá linh hoạttất nhiên dễ dàng thực hiện, sử dụng và hỗ trợ nhiều ứng dụng với sự điều chỉnh nhỏ nhất.

Các biến thể tinh vi của RBAC bao gồm khả năng thiết lập mối quan hệ giữa các role cũng như là giữa các permission và các role và giữa các user với các role.

Ví dụ, hai role có thể đươc lập sao cho loại trừ nhau do đó cùng một user không đựơc phép thực hiện cả hai role. Các role cũng có thể có quan hệ kế thừa, theo đó một role kế thừa các permission được gắn cho role khác. Những mối quan hệ role – role này có thể được sử dụng để làm cho các chính sách bảo mật bao gồm sự tách rời các công việc và sự ủy thác của người có thẩm quyền. Từ trước đến nay những mối quan hệ này đựợc mã hóa trong phần mềm ứng dụng, với RBAC, chúng đựợc định rõ một lần cho một miền bảo mật.

Với RBAC, người ta có thể xác định được các mối quan hệ role – permission. Điều này giúp cho việc gán cho các user tới các role xác định dễ dàng. Bản nghiên cứu NIST [1] chỉ ra rằng các permission được phân cho các role có xu hướng thay đổi tương đối chậm so với sự thay đổi thành viên những user các role. Nghiên cứu này cũng đã nhận thấy việc cho phép các quản trị viên cấp hoặc hủy bỏ tư cách thành viên của các user trong các role đang tồn tại mà không cho các quản trị viên này quyền tạo role mới hay thay đổi sự phân chia role – permission là điều đang đựợc mong muốn.

Việc phân công các user theo role sẽ cần ít kĩ năng kĩ thuật hơn việc phân công các permission theo role. Nếu không có RBAC, việc xác định permission nào được ủy thác cho user nào sẽ khó.

Chính sách điều khiển truy cập được thể hiện ở các thành tố khác nhau của RBAC như mối quan hệ role – permission, mối quan hệ user – role và mối quan hệ role – role. Những thành tố này cùng xác định xem liệu một user cụ thể có được phép truy cập vào môt mảng dữ liệu trong hệ thống hay không. Các thành tố RBAC có thể đựợc định dạng trực tiếp bởi người sở hữu hệ thống hay gián tiếp bởi các role thích hợp mà người sở hữu hệ thống ủy thác. Chính sách có hiệu lực trong một hệ cụ thể nào đó là kết quả cuối cùng của việc định dạng các thành tố RBAC khác nhau một cách trực tiếp bởi người sở hữu hệ thống. Ngoài ra chính sách điều khiển truy cập có thể gia tăng trong chu kì của hệ thống và ở các hệ lớn điều này là chắc chắn xảy ra. Khả năng biến đổi chính sách để đáp ứng được nhu cầu đang thay đổi của một tổ chức là một lợi ích quan trọng của RBAC.

Mặc dù RBAC là một chính sách trung lập, nó trực tiếp hỗ trợ ba nguyên tắc bảo mật nổi tiếng: đặc quyền ít nhất, sự tách biệt các nhiệm vụ, trừu tượng hóa dữ liệu. Nguyên tắc đặc quyền ít nhất đựợc hỗ trợ vì RBAC được định dạng do đó chỉ những permission mà nhiệm vụ do các thành viên của role quản lí đó cần mới được phân cho role đó. Sự tách biệt các nhiệm vụ đạt được bằng cách đảm bảo những role có quan hệ loại trừ lẫn nhau phải đựơc sử dụng tới để hoàn thành một công việc nhạy cảm như yêu cầu một nhân viên kế toán và một quản lí kế toán tham gia vào phát hành một tấm Sec. Trừu tượng hóa dữ liệu được hỗ trợ bằng các permission trừu tượng như credit (bên có) và debit (bên nợ) cho một tài khoản, chứ không phải là các permission đọc, viết, quản lí thường đựợc hệ điều hành cung cấp. Tuy nhiên, RBAC không cho phép ứng dụng các nguyên lý này. Nhân viên bảo mật có thể định dạng được RBAC do đó nó vi phạm những nguyên lí này. Ngoài ra, mức độ trừu tuợng hóa dữ liệu đựợc hỗ trợ sẽ do các chi tiết bổ sung quyết định.

2.3. Các vai trò và các khái niệm liên quan

Một câu hỏi thường được hỏi là “sự khác nhau giữa các role và các group là gì?”. Các nhóm user như một đơn vị kiểm soát truy cập thường được nhiều hệ thống kiểm soát truy cập cung cấp. Điểm khác biệt chính giữa hầu hết các group và khái niệm role là group thường đựợc đối xử như một tập hợp những user chứ không phải là một tập hợp các permission. Một role một mặt vừa là một tập hợp các user mặt khác lại là một tập hợp các permission. Role đóng vai trò trung gian để kết nối hai tập hợp này lại với nhau.

Hãy xem xét hệ điều hành Unix. Thành viên nhóm trong Unix được xác định ở trong hai file /ect/password và /ect/group. Do đó để xác định một user cụ thể thuộc group nào hoặc xác định tất cả các thành viên của một group cụ thể là khá dễ dàng. Các permission giành cho các nhóm dựa vào các permission kết hợp với các file cá nhân và các thư mục. Để xác định permission nào một nhóm cụ thể thường có sẽ cần sự nghiên cứu kĩ luỡng cả một cây hệ thống file. Do đó việc xác định thành viên của nhóm thường dễ hơn việc xác định permission của nhóm. Ngoài ra, việc giao permission cho nhóm được phi tập trung hóa cao. Về cơ bản, người sở hữu một sub-tree (cây con) của hệ thống file Unix có thể giao permission của sub-tree đó cho một nhóm. (mức độ chính xác việc này có thể làm được phụ thuộc vào dạng Unix cụ thể được nói đến). Tuy nhiên, nhóm Unix có thể được dùng để thực hiện role trong hoàn cảnh cụ thể mặc dù theo khái niệm role của chúng tôi các nhóm không giống nhau.

Để minh họa bản chất sự khác biệt của group và role, hãy xem xét hệ thống mang tính giả thuyết mà cần gấp đôi thời gian để xác định thành viên nhóm so với xác định permission của nhóm. Hãy cho rằng permission của nhóm và thành viên nhóm chỉ có thể được nhân viên bảo mật hệ thống thay đổi. Trong trường hợp này, cơ chế nhóm sẽ trở nên rất gần với khái niệm role của chúng tôi.

Một vấn đề được quan tâm nữa là mối quan hệ giữa role và Compartment. Compartment là một phần của cấu trúc nhãn bảo mật được sử dụng trong quốc phòng hay các cơ quan nhà nước. Compartment dựa vào quan điểm cần là biết (need-to-know) có nghĩa rộng đối với thông tin có sẵn ở một nhãn compartment tương tự nghĩa ngữ nghĩa của role. Tuy nhiên, người ta sử dụng compartment cho một chính sách sở hữu thông tin một chiều riêng biệt trong hàng rào các nhãn. Role không thực hiện chính sách nào thuộc loại này cả.

Lâu nay vẫn tồn tại sự khác biệt giữa kiểm soát truy cập theo ý muốn và kiểm soát truy cập bắt buộc được biết đến lần lượt là DAC và MAC. Sự khác biệt này xuất hiện khi người ta nghiên cứu bảo mật trong ngành quốc phòng. MAC cho phép việc kiểm soát truy cập dựa vào nhãn bảo mật gửi kèm tới các user (chính xác hơn là chủ thể) và khách thể (object). DAC cho phép kiểm soát truy cập thực hiên được đối với khách thể (object) dựa trên cơ sở permission hoặc từ chối hoặc cả hai do một user riêng biệt, thường là người sở hữu object đó định dạng. RBAC có thể được xem như một thành tố kiểm soát truy cập độc lập, cùng tồn tại với MAC và DAC lúc thích hợp. Trong trường hợp này việc truy cập sẽ được phép nếu RBAC, MAC và DAC cho phép. Hi vọng rằng RBAC trong nhiều trường hợp sẽ tự nó tồn tại.

Như một vấn đề liên quan, RBAC bản thân nó là một cơ chế tùy ý hay bắt buộc? Câu trả lời phụ thuộc vào định nghĩa chính xác của cái quan niệm “tùy ý” và “bắt buộc” cũng như là bản chất thực và sự định hình các permission, role và user trong một hệ thống RBAC. Việc hiểu bắt buộc có nghĩa là các user cá nhân không có sự lựa chọn nào đối với việc permission hoặc user nào được giao đến một role nào, trong khi tùy ý có nghĩa là user được tự đưa ra các quyết định này. Như đã nói ở trên, RBAC bản thân nó là một chính sách trung tính. Các dạng nhất định nào đó của RBAC có thể là bắt buộc, trong khi các dạng khác có thể lại là tùy ý.

Каталог: jspui -> bitstream -> 123456789
123456789 -> Nguyễn Ngọc Lý Giám đốc Trung tâm Nghiên cứu về Môi trường và Cộng đồng
123456789 -> Vò Quúnh Thu Cao häc K18
123456789 -> Khoa Báo chí Đhkhxh&NV
123456789 -> Acknowledgements
123456789 -> Danh mục chữ viết tắT
123456789 -> Chương TỔng quan vật liệu mao quản trung bình (mqtb) trật tự 1 Giới thiệu chung
123456789 -> Khoa hóa họC (141 142 báo cáo)

tải về 296.99 Kb.

Chia sẻ với bạn bè của bạn: