Khóa luận Nghiên cứu ngôn ngữ đặc tả Security Policy và xây dựng công cụ hỗ trợ

huỗi các sự kiện. Các dạng khác của điều khiển truy cập có thể được đặt ở tầng trên của RBAC cũng chính vì mục đích này. 3.2. Vai trò và các định nghĩa liên quan Với RBAC các nhà phát triển tạo ra các vai trò theo các chức năng công việc được thực hiện trong công ty hay tổ chức, cấp các quyền cho các vai trò này và sau cùng là gán những người sử dụng vào các vai trò này dựa trên cơ sở trách nhiệm và năng lực của công việc đặc thù đó. Một vai trò có thể trình bày một nhiệm vụ cụ thể như là một vai trò bác sĩ hay vai trò một nhà điều hành kinh doanh. Một vai trò bao gồm quyền và trách nhiệm trong đó quyền và trách nhiệm được phân biệt rất rõ ràng. Một người có thể có quyền quản lý nhiều phòng ban nhưng anh ta chỉ có trách nhiệm đối với phòng ban cụ thể được quản lý. Các vai trò cũng có thể phản ánh trách nhiệm cụ thể được gán vòng quanh qua nhiều người sử dụng, ví dụ như trách nhiệm của một bác sĩ hay một nhân viên làm ca. Các vai trò định nghĩa cả sự cho phép riêng biệt cụ thể để truy cập các tài nguyên và quy mô của các tài nguyên được truy cập. Lấy ví dụ một vai trò người điều hành có thể truy cập tất cả các tài nguyên máy tính nhưng không thể thay đổi các quyền truy cập của mình, hay một kiểm toán viên chỉ có thể truy cập vào máy tính để kiểm tra sổ sách. Các vai trò được sử dụng để quản trị hệ thống trong nhiều hệ điều hành mạng như NetWare của Novell hay WindowNT của Microsoft. Sự kết hợp của người sử dụng và các quyền tạo nên một vai trò. Các quyền được gán một cách gián tiếp cho người sử dung thông qua một vai trò, chính vì thế mà việc bảo mật các lỗ hổng trên các vai trò đơn giản hơn rất nhiều so với trên các quyền. Người sử dụng có thể được gán lại sang các vai trò khác nếu cần thiết. Một câu hỏi thường xuyên được đặt ra là “Đâu là điểm khác nhau giữa các vai trò (role) và các nhóm (group)”. Nhóm người sử dụng là một đơn vị của điều khiển truy cập khá phổ biến được cung cấp bởi các hệ thống điều khiển truy cập. Một chuyên đề khác giữa hầu hết những sự cài đặt của các nhóm và định nghĩa của các vai trò đó là: nhóm là một chuẩn giao tiếp giống như một tập hợp người sử dụng và không phải là tập hợp của các quyền. Một vai trò là cả một tập hợp của người sử dụng ở một bên và một tập hợp các quyền ở một bên khác. Vai trò hoạt động như một người trung gian để nhóm hai tập hợp đó lại với nhau. 3.3. Họ mô hình RBAC Về cơ bản, RBAC được chia thành bốn mức khác nhau, từ mức cơ sở đến mức nâng cao như hình vẽ dưới đây: Hình 2: Họ RBAC 3.3.1. Core RBAC (RBAC 0) Trong hình trên (hình 2), RBAC 0 base model [6] là mô hình cơ bản nhất cho các hệ thống RBAC và chứa năm phần tử dữ liệu cơ bản đó là: Users (U): tập hợp người sử dụng Roles (R): tập hợp các vai trò Permissions (PRMS) : các quyền Objects (OBS) : các đối tượng Operations (OPS): các hành động Trong mô hình RBAC, người sử dụng có thể là con người, các cỗ máy, các mạng…chứ không nhất thiết phải mang yếu tố con người. Một vai trò trình bày một chức năng công việc (job-function). Các quyền là một sự phê chuẩn để thực thi các hành động (operations) trên một hay nhiều đối tượng, các quyền phải luôn luôn rõ ràng, có thể áp dụng cho nhiều đối tượng và phải được miêu tả một cách trừu tượng, thêm vào đó các quyền chỉ có thể có tác dụng đối với các đối tượng dữ liệu và tài nguyên của hệ thống mà không thể có tác dụng đối với các thành phần RBAC. Đối với các thành phần RBAC chỉ có các quyền quản trị mới có thể thao tác được. Mô hình tổng quát của RBAC 0 được mô tả như trong hình 3 dưới đây: Hình 3. Mô hình tổng quát Core RBAC Ngoài ra trong mô hình trên ta còn thấy một thành phần nữa đó là Session (S). Session đánh dấu phiên làm việc của người sử dụng, mỗi một session sẽ ánh xạ đến duy nhất một người sử dụng và một tập hợp con các vai trò được kích hoạt mà người sử dụng được gán tới. Điều đó có nghĩa rằng tại một thời điểm, một user có thể có nhiều phiên làm việc và nhiều vai trò có thể được kích hoạt tại cùng một thời điểm đó. Session chính là nhân tố quyết định xem liệu hệ thống có cho phép người sử dụng thực hiện multi login hay không, hay cũng có thể dùng session để kiểm tra xem hiện tại có bao nhiêu người đang truy cập hệ thống… Một cách tổng quát nhất, RBAC có thể được định nghĩa như sau: U, R, PRMS và S trình bày theo thứ tự tập hợp Users – những người sử dụng, Roles – các vai trò, Permisstions – các quyền, và Sessions – các phiên. RH R X R là một phần t rên các vai trò, được gọi là mối quan hệ ưu thế, được viết tắt là , và định nghĩa một thứ tự các vai trò, đó là r1 r2, với (r1, r2) R. UA U X R là mối quan hệ gán những người sử dụng với các vai trò. assign_roles(u:U)à , là ánh xạ của một người sử dụng lên trên một tập các vai trò mà cô ta/anh ta được gán. Chính xác hơn: assign_roles(u) = {r R | (u, r) UA}. assign_users(r:R)à , là ánh xạ của một vai trò lên trên một tập người sử dụng được gán vai trò này. Chính xác hơn: assign_users(r) = {u U | (u, r) UA}. PA R X PRMS, là mối quan hệ gán một quyền cho một vai trò. assign_perms(r:R)à , là ánh xạ của một vai trò lên trên một tập hợp các quyền. Chính xác hơn: assign_perms(r) = {p PRMS | (r, p) PA}. user_ses(u:U)à , là ánh xạ của một người sử dụng lên trên một tập các phiên. Ses_roles(s:S)à , là ánh xạ của mỗi một phiên tới một tập vai trò. avail_session_perms(s:S)à , các quyền sẵn có trong một phiên, đó là assign_perms(r). 3.3.2. Role hierarchy RBAC 1 tích hợp thêm Role Hierarchy – RH [3] hay còn gọi là hệ thống cấp bậc trong vai trò. Mô hình tổng quát của RBAC 1 như sau: Hình 4. Mô hình tổng quát Role hierarchy ( RBAC 1) RH định nghĩa một quan hệ kế thừa giữa các vai trò, sự kế thừa đó được miêu tả bên trong các nhóm quyền, ví dụ như vai trò r1 kế thừa vai trò r2 nếu như tất cả các đặc quyền của r2 cũng là các đặc quyền của r1 ngoài ra r1 có thể có thêm một số quyền khác. Trong một vài cài đặt cụ thể của RBAC, các quyền không được quản lý một cách tập trung trong khi đó RH lại được quản lý tập trung. Với các hệ thống đó RH được quản lý bên trong các nhóm người sử dụng chứa đựng các quan hệ, vai trò r1 chứa đựng vai trò r2 nếu như tất cả người sử dụng được xác thực cho r1 cũng là những người sử dụng được xác thực cho r2. Chú ý rằng, một người sử dụng của r1 có tất cả các đặc quyền của r2, trong khi sự kế thừa quyền cho r1 và r2 không nói đến bất cứ điều gì về UA (User Assignment). Có hai kiểu RH đó là: General Role Hierarchies (RH tổng quát) Limited Role Hierarchies (RH giới hạn). 3.3.2.1. General Role Hierarchies General Role Hierarchies hỗ trợ định nghĩa đa kế thừa (multiple inheritance). Điều này có nghĩa rằng nó cung cấp khả năng kế thừa quyền cũng như việc kế thừa user membership từ hai hay nhiều vai trò nguồn. RH ROLES × ROLES được gọi là quan hệ kế thừa, viết tắt là ,r1 r2 chỉ khi tất cả các quyền của r2 cũng là các quyền của r1 và tất cả người sử dụng của r1 cũng là những người sử dụng của r2. r1r2è authorized_permissions(r2)⊆ authorized_permissions(r1) authorized_users(r: ROLES) → 2^USERS, ánh xạ vai trò r lên trên một tập hợp người sử dụng trong sự hiện diện của một RH, authorized_users(r) = {u USERS | r’ r , (u, r’) UA} authorized_permissions(r: ROLES) → 2^PRMS, ánh xạ vai trò r lên trên một tập hợp các quyền trong sự hiện diện của một RH. authorized_permissions(r) = {p PRMS | r’ r, (p, r’) PA} 3.3.2.2. Limited Role Hierarchies Limited Role Hierarchies không hỗ trợ định nghĩa đa kế thừa Định nghĩa giống như RH tổng quát nhưng có thêm giới hạn sau đây: r, r1, r2 ROLES, rr1 ∧ rr2 ⇒ r1 = r2 3.3.3. Constrained RBAC Constrained RBAC [3] thêm các quan hệ Separation of Duty (SoD - sự phân chia trách nhiệm) vào mô hình RBAC. SoD được sử dụng để thực thi các chính sách xung đột lợi ích mà các tổ chức có thể sử dụng để ngăn chặn người sử dụng vượt quá một mức độ hợp lý cho các quyền của họ. Giống như một yếu tố bảo mật cơ bản, SoD đã được công nhận một cách rộng rãi cho các ứng dụng trong kinh doanh, các ngành công nghiệp và chính phủ. Mục đích của nó là để đảm bảo rằng các sai sót và gian lận bên trong một tổ chức chỉ là kết quả của việc thông đồng giữa các cá nhân. Để giảm thiểu khả năng thông đồng, các cá nhân thuộc các nhóm kỹ năng khác nhau hoặc lợi ích khác nhau được phân công nhiệm vụ cần thiết và riêng biệt trong việc thực hiện các chức năng của một doanh nghiệp. Động lực ở đây chính là để đảm bảo rằng các sai sót và gian lận không xảy ra và cũng không có việc thông đồng của nhiều người sử dụng. Chuẩn RBAC này cho phép cả SoD tĩnh và SoD động. 3.3.3.1 . Các quan hệ Static SoD (SSD) Chúng ta biết rằng trong một hệ thống RBAC, một người sử dụng có thể ở trong một hoặc nhiều vai trò khác nhau. Như vậy, một câu hỏi đặt ra là liệu có sự sung đột về lợi ích của người sử dụng hay không khi trong trường hợp họ ở trong hai vai trò khác nhau mà hai vai trò này lại mâu thuẫn với nhau? Câu trả lời là điều này hoàn toàn có thể xảy ra, chúng ta hãy lấy ví dụ: Trong một nhà băng, một nhân viên thu ngân (teller) có thể thực hiện hành động lưu các khoản tiền mà khách hàng gửi vào tài khoản của mình trong ngân hàng. Để thực hiện hành động này, nhân viên thu ngân phải truy cập để đọc và viết vào các trường đặc biệt bên trong một file. Trong lúc này, nhân viên giám sát tài khoản (accounting supervisor) có thể thực hiện hành động chỉnh sửa thông tin của các tài khoản bằng cách truy cập để đọc và viết lên các trường trong file mà nhân viên thu ngân đã mở ra và thêm dữ liệu ở trên. Tuy nhiên theo quy định của ngân hàng thì nhân viên giám sát tài khoản không được phép khởi tạo hay dỡ bỏ đối với một tài khoản mà chỉ được phép chỉnh sửa thông tin của tài khoản và nhân viên thu ngân không được phép thực hiện chỉnh sửa những giao tác mà anh ta đã hoàn thành. Như vậy thông qua ví dụ trên chúng ta thấy rõ rằng, vai trò nhân viên thu ngân (teller) và vai trò nhân viên giám sát (accounting supervisor) là hai vai trò hoàn toàn trái ngược nhau hay nói cách khác là xung đột nhau, và sẽ không bao giờ có chuyện một nhân viên trong ngân hàng vừa đóng vai trò nhân viên thu ngân vừa đóng vai trò nhân viên giám sát tài khoản. Quan hệ SSD được đưa ra để giải quyết các vấn đề xung đột lợi ích như đã nói ở trên. Mô hình tổng quát các quan hệ SSD được minh họa trong hình 5 dưới đây: Hình 5: Mô hình tổng quát các quan hệ SSD là một tập hợp của cặp (rs, n) trong Static SoD, nơi mà mỗi rs là một tập hợp vai trò, t là một tập hợp con của rs, và n là một số tự nhiên >= 2, với đặc tính rằng không có người sử dụng được gán tới n hoặc nhiều vai trò từ tập hợp rs trong mỗi cặp (rs, n) Dạng tổng quát: Như vậy, các chính sách SSD ngăn ngừa các xung đột bằng cách đặt các ràng buộc lên các hành động quản lý mà qua đó giới hạn việc kết hợp các đặc quyền của người sử dụng. 3.3.3.2. Các quan hệ Dynamic SoD (DSD) Các quan hệ Dynamic SoD cũng giống như các quan hệ Static SoD ở chỗ cả hai đều được sử dụng để giới hạn các quyền có thể được cung cấp đến người sử dụng. Tuy nhiên, các quan hệ DSD khác với các quan hệ SSD ở ngữ cảnh mà trong đó những sự giới hạn đó được áp đặt. Các mối quan hệ SSD định nghĩa và đặt các ràng buộc trên khu vực tổng số quyền của người sử dụng, còn DSD lại đặt các ràng buộc lên trên các vai trò có thể được kích hoạt trong một phiên làm việc của người sử dụng. DSD cho phép một user được xác thực cho hai hoặc nhiều vai trò mà không tạo ra một sự xung đột lợi ích giữa các vai trò khi chúng hoạt động độc lập. Điều này có nghĩa rằng nếu một vai trò thuộc một quan hệ SSD được kích hoạt trong phiên làm việc của người sử dụng thì các vai trò có liên quan khác không thể được kích hoạt trong cùng một phiên làm việc đó. Mô hình tổng quát của các quan hệ DSD được minh họa như trong hình d dưới đây: Hình 6: Mô hình tổng quát các quan hệ DSD là tập hợp của cặp (rs, n) trong DSD, trong đó mỗi rs là một tập hợp các vai trò và n là một số tự nhiên >= 2, với đặc tính là không có chủ thể nào có thể kích hoạt n hay nhiều vai trò từ tập hợp rs trong mỗi dsd thuộc DSD. Dạng tổng quát và 3.3.4. RBAC 3 Là sự kết hợp của RBAC 1 (Role Hirerachy) và RBAC 2 (Constrained RBAC). Mô hình tổng quát như sau: Hình 7: Mô hình tổng quát RBAC cấp cao nhất - RBAC 3 Một cách chi tiết hơn: Hình 8: Mô hình RBAC cấp cao nhất – triển khai chi tiết Mô hình RBAC 3 [5] được triển khai bằng ngôn ngữ mô hình hóa UML. Chú ý: trong hình 4.4.2, chúng ta thấy các vai trò được phân làm hai loại Roles – vai trò thông thường và Administrative Role – vai trò quản trị đó là bởi vì trong mô hình RBAC các vai trò thông thường chỉ có quyền thao tác trên dữ liệu và tài nguyên thông thường của hệ thống còn đối với các thành phần thuộc RBAC(U, R, S,PRMS,…) thì các vai trò thông thường này không có quyền thao tác. Chính vì thế các vai trò quản trị được định nghĩa cho ra để cho phép quản lý các thành phần RBAC. 3.4. Hệ thống RBAC và đặc tả các chức năng quản trị 3.4.1. Core RBAC 3.4.1.1. Administrative commands cho core RBAC AddUser Tạo ra một người sử dụng mới. Câu lệnh này chỉ có hiệu lực khi mà người sử dụng này chưa là thành viên của tập hợp USERS dataset(chưa có tài khoản trong hệ thống). Sau khi thêm mới người sử dụng USERS dataset sẽ được cập nhật. DeleteUser Xóa bỏ một người sử dụng đang tồn tại trong cơ sở dữ liệu RBAC. Câu lệnh chỉ có hiệu lực khi người sử dụng đang là thành viên của USERS dataset. Sau khi xóa thành công USERS, UA dataset và phương thức assigned_users sẽ được cập nhật. AddRole Tạo ra một vai trò mới. Lệnh này chỉ thực sự có hiệu lực nếu và chỉ nếu vai trò này chưa là một thành viên của ROLES dataset. Hình thức hóa chức năng này như sau: DeleteRole Xóa bỏ một vai trò đang tồn tại trong cơ sở dữ liệu RBAC. Câu lệnh này chỉ có tác dụng nếu và chỉ nếu vai trò cần xóa này đang là một thành viên của ROLES dataset. Hình thức hóa chức năng này như sau: AssignUser Gán một người sủ dụng vào một vai trò. Câu lệnh chỉ có tác dụng nếu và chỉ nếu người sử dụng đang là một thành viên của USERS dataset và vai trò mà người sử dụng được gán vào phải đang là thành viên của ROLES dataset. Hình thức hóa chức năng này như sau: DeassignUser Loại bỏ một người sử dụng khỏi một vai trò. Câu lệnh này chỉ có tác dụng nếu và chỉ nếu người sử dụng đang là một thành viên của USERS dataset, vai trò mà người sử dụng sẽ bị loại ra đang là thành viên của ROLES dataset và người sử dụng đã được gán vào vai trò này từ trước đó. Hình thức hóa chức năng này như sau: GrantPermission Cấp cho vai trò một số quyền để có thể thao tác trên các đối tượng. Lệnh này chỉ có tác dụng nếu như vai trò này đang là thành viên của ROLES dataset. Hình thức hóa chức năng này như sau: RevokePermission Gỡ bỏ các quyền đã cấp cho một vai trò. Lệnh này chỉ có tác dụng nếu như vai trò này đang là thành viên của ROLES dataset. Hình thức hóa chức năng này như sau: 3.4.1.2. Các chức năng hỗ trợ hệ thống cho core RBAC CreateSession(user, session) Tạo ra một session – hay phiên làm việc mới. hàm này sẽ được gọi khi người dùng lần đầu tiên đăng nhập vào hệ thống đồng thời sẽ kích hoạt tất cả vai trò mà đang quản lý người sử dụng này. Qúa trình tạo ra một session này chỉ có tác dụng nếu và chỉ nếu: Người sử dụng là thành viên của USERS dataset Tập hợp các vai trò được kích hoạt là một tập con của tập tất cả các vai trò được gán tới người sử dụng Hình thức hóa chức năng này như sau: DeleteSession(user, session) Xóa bỏ một session gắn với một người sử dụng. Hàm này chỉ có tác dụng nếu và chỉ nếu session identifier là một thành viên của SESSION dataset, người sử dụng là một thành viên của USERS dataset và session này được nắm giữa bởi người sử dụng hiện tại. Hình thức hóa chức năng này như sau: AddActiveRole Hàm này sẽ thêm mới một vai trò giống như một vai trò được kích hoạt trong một session.mà một người sử dụng đang ánh xạ đến. hàm này chỉ có tác dụng nếu và chỉ nếu: Người sử dụng là thành viên của USERS dataset Vai trò là thành viên của ROLES dataset Session identifier là thành viên của SESSION dataset Vai trò này đã được gán cho người sử dụng hiện tại từ trước Session đang được nắm giữ bởi người sử dụng Hình thức hóa chức năng này như sau: DropActiveRole Xóa một vai trò ra khỏi tập hợp các vai trò đang được kích hoạt trong một session đang ánh xạ đến một người sử dụng. hàm này trái ngược lại với hàm AddActiveRole. Hình thức hóa chức năng này như sau: CheckAccess Hàm này trả về một giá trị Boolean để kiểm tra xem chủ thể của một session có được phép thực hiện một hành động nào đó (operaion) lên một đối tượng nào đó hay không. Hàm này chỉ có tác dụng nếu và chỉ nếu: Session indentifier là thành viênc của SESSION dataset. Đối tượng là một thành viên của OBJ dataset Operation là một thành viên của OPS dataset Quyền này đã được cấp cho một trong các vai trò đã được kích hoạt của session này Hình thức hóa chức năng này như sau: 3.4.1.3. Các chức năng review cho Core RBAC AssignedUsers Hàm này trả về một tập hợp người sử dụng đã được gán tới một vai trò nào đó. Hàm này chỉ có tác dụng nếu và chỉ nếu vai trò là một thành viên của ROLES dataset. Hình thức hóa chức năng này như sau: AssignedRoles Hàm này trả về một tập hợp các vai trò đã được gán tới một người sử dụng nào đó. Hàm này chỉ có tác dụng nếu và chỉ nếu người sử dụng là thành viên của USERS dataset. Hình thức hóa chức năng này như sau: 3.4.1.4. Các chức năng review cao cấp cho Core RBAC RolePermissions Hàm này trả về một tập hợp các quyền (op, obj) được cấp cho một vai trò. Hàm này chỉ có tác dụng nếu và chỉ nếu vai trò là thành viên của ROLES dataset. Hình thức hóa chức năng này như sau: UserPermissions Hàm này trả về các quyền mà một người sử dụng được cấp thông qua vai trò của anh ta/cô ta được gán. Hàm này chỉ có tác dụng nếu và chỉ nếu người sử dụng là một thành viênc của USERS dataset. Hình thức hóa chức năng này như sau: SessionRoles Hàm này trả về các quyền một session nào đó. Các quyền này được cấp cho các vai trò đang được kích hoạt bởi session. Hàm này chỉ có tác dụng nếu và chỉ nếu session indentifier là một thành viên của SESSION dataset. Hình thức hóa chức năng này như sau: RoleOperationsOnObject Hàm này trả về một tập hợp các hành động mà một vai trò được phép thực hiện trên một tập hợp đối tượng nào đó. Hàm này chỉ có tác dụng nếu và chỉ nếu vai trò là một thành viên của ROLES dataset, đối tượng là một thành viên của OBJ dataset. Hình thức hóa chức năng này như sau: UserOperationsOnObject Hàm này trả về một tập hợp các quyền mà một người sử dụng có thể được phép thực thi trên một tập hợp đối tượng nào đó. Hàm này chỉ có tác dụng nếu và chỉ nếu người sử dụng là thành viên của USERS dataset, đối tượng là thành viên của OBJ dataset. Hình thức hóa chức năng này như sau: 3.4.2. Role hierarchy 3.4.2.1. Administrative commands cho role hierarchy tổng quát AddInheritance câu lệnh này khởi tạo một quan hệ kế thừa trực tiếp giữa các vai trò r_asc và r_desc. Câu lệnh này chỉ có tác dụng nếu và chỉ nếu r_asc và r_desc là thành viên của ROLE data set, r_desc chưa kếu thừa r_asc . schema dưới đây sử dụng các ký hiệu: Hình thức hóa chức năng này như sau: DeleteInheritance Câu lệnh này xóa bỏ một mối quan hệ kế thừa giữa r_asc và r_desc. Lệnh này chỉ có tác dụng nếu và chỉ nếu r_asc và r_desc là thành viên của ROLE dataset và r_desc đang kế thừa r_asc. Hình thức hóa chức năng này như sau: AddAscendant Câu lệnh này tạo ra một vai trò mới có tên r_asc, và thêm nó vào trong role hieararchy giống như nó là đối tượng cơ sở của r_desc. Câu lệnh này chỉ có tác dụng nếu và chỉ nếu r_asc chưa là một thành viên của ROLE dataset, r_desc là thành viên của ROLE data set. Hình thức hóa chức năng này như sau: AddDescendant Câu lệnh này thực hiện việc tạo ra một vai trò mới có tên r_desc và thêm nó vào role hierarchy giống như nó không phải là đối tượng kế thừa của r_asc. Câu lệnh này chỉ có tác dụng nếu và chỉ nếu r_desc chưa phải là thành viên của ROLE data set. Hình thức hóa chức năng này như sau: 3.4.2.2. Các chức năng hệ thống cho role hierarchy CreateSession(user, session) Câu lệnh này khởi tạo ra một phiên làm việc mới cho một người sử dụng đồng thời điều chỉnh các vai trò được kích hoạt. câu lệnh này chỉ có tác dụng nếu và chỉ nếu: Người sử dụng là một thành viên của USER data set Vai trò được kích hoạt là thành viên của tập các vai trò được phép xác thực cho người sử dụng này. Chú ý rằng khi một vai trò được kích hoạt cho một phiên làm việc thì các vai trò kế thừa nó cũng như các vai trò nó kế thừa sẽ không được phép kích hoạt cho session này. Hình thức hóa chức năng này như sau: AddActiveRole Câu lệnh kích hoạt một vai trò mới cho một phiên làm việc của một người sử dụng. câu lệnh này chỉ có tác dụng nếu và chỉ nếu: Người sử dụng là thành viên của USER data set Vai trò được kích hoạt mới là thành viên của ROLE data set Phiên làm việc hiện tại là thành viên của SESSION data set Người sử dụng được xác thực cho vai trò đó, và Session được nắm giữ bởi người sử dụng này Hình thức hóa chức năng này như sau: 3.4.2.3. Các chức năng review cho role hierarchy tổng quát AuthorizedUsers Câu lệnh này trả lại một tập hợp những người sử dụng được xác thực cho một vai trò hiện tại. Những người sử dụng này được gán tới một vai trò mà vai trò này lại kế thừa vai trò hiện tại. Câu lệnh này chỉ có tác dụng nếu và chỉ nếu vai trò hiện tại là thành viên của ROLE data set. Hình thức hóa chức năng này như sau: AuthorizedRoles Câu lệnh này trả lại một tập hợp các vai trò được xác thực cho một người sử dụng. Câu lệnh này chỉ có tác dụng nếu và chỉ nếu người sử dụng là thành viên của USER data set. Hình thức hóa chức năng này như sau: 3.4.2.4 – Các chức năng review cao cấp cho role hierarchy RolePermissions Câu lệnh này trả về một tập hợp tất cả các quyền (op, obj) được gán hoặc được kế thừa bởi một vai trò hiện tại. Câu lệnh này chỉ có tác dụng nếu và chỉ nếu vai trò hiện tại là thành viên của ROLE data set. Hình thức hóa chức năng này như sau: UserPermissions Câu lệnh này trả lại một tập hợp các quyền của một người sử dụng, được lấy thông qua các vai trò được xác thực của anh ta. Câu lệnh này chỉ tồn tại nếu và chỉ nếu người sử dụng là thành viên của USER data set. Hình thức hóa chức năng này như sau: RoleOperationsOnObject Câu lệnh này trả lại một tập hơp các hành động mà một vai trò được phép thực hiện trên một đối tượng hiện tại. Tập hợp này chứa đựng toàn bộ các hành động được gán trực tiếp cho vai trò hay vai trò hiện tại kế thừa từ các vai trò khác. Câu lệnh này chỉ có tác dụng nếu và chỉ nếu vai trò là một thành viên của ROLE data set, đối tượng hiện tại là một thành viên của OBJS data set. Hình thức hóa chức năng này như sau: UserOperationsOnObject Câu lệnh này trả lại một tập hợp các hành động mà một người sử dụng được phép thực hiện trong trên một đối tượng hiện tại. Tập hợp này chứa đựng tất cả các hành động của người sử dụng thông qua các vai trò được xác thực của anh ta. Câu lệnh này chỉ có tác dụng nếu và chỉ nếu người sử dụng là thành viên của USER data set. Đối tượng hiện tại là thành viên của OBJS data set. Hình thức hóa chức năng này như sau: CHƯƠNG 4. PHÂN TÍCH VÀ THIẾT KẾ CÔNG CỤ HỖ TRỢ Trong chương này chúng tôi sẽ tập trung vào việc thiết kế một ứng dụng minh họa việc triển khai mô hình RBAC vào cài đặt thực tế để quản lý và điều khiển truy cập. Ứng dụng này sẽ tập trung vào việc mô tả và cài đặt những chức năng cơ bản nhất mà một hệ thống RBAC phải có. Các chức năng này bao gồm : chức năng quản lý các vai trò, quản lý người sử dụng, quản lý các đối tượng và quyền thực thi trên các đối tượng này, quản lý các đặc quyền của các vai trò. Việc cài đặt mô hình RBAC sao cho đảm bảo được mọi yêu cầu như: xử lý các ràng buộc, các xung đột quyền lợi, kiểm tra hiệu năng… mà lý thuyết đã chỉ ra là một việc không hề đơn giản, đòi hỏi nhiều thời gian và công sức cũng như kinh nghiệm. Trong khuân khổ của khóa luận này, chúng tôi sẽ tạm thời không xử lý đến những vấn đề đó. Mục đích chính của việc cài đặt này là làm sáng tỏ hơn các khái niệm vai trò (role), các quyền (permission), hay các phiên làm việc (session). Mặt khác chúng ta biết rằng mô hình RBAC được đưa ra để áp dụng cho những ứng dụng đa người dùng (multi user), chính vì lý do đó chúng tôi quyết định triển khai ứng dụng trên nền web – một kiểu ứng dụng đa người dùng phổ biến nhất hiện nay. Việc triển khai RBAC trên nền web cũng là một việc hết sức thiết thực bởi thế giới công nghệ đang chuyển mình nhanh chóng sang nền web, các ứng dụng chỉ chạy trên desktop đã dần trở nên lỗi thời và bộc lộ nhiều bất cập. Một điểm nữa là theo truyền thống, các ứng dụng web thường chia làm hai phần riêng biệt: phần dành cho người quản trị (back-end) và phần dành cho người sử dụng bình thường. Tuy nhiên như đã thảo luận ở trên, ứng dụng của chúng ta áp dụng mô hình RBAC vào để quản lý và điều khiển truy cập. Với lý do đó chúng tôi chỉ xây dựng phần dành cho người quản trị, bởi đây là khu vực mà người quản trị bảo mật sẽ làm việc, điều khiển, cấp quyền truy cập cho các vai trò tới các tài nguyên của hệ thống, quản lý và theo