View–Based Access Model ORACLE

MỤC LỤC Lời mở đầu 3 CHƯƠNG 1 4 Giới thiệu các khái niệm và cú pháp của View Policy Language 4 1.1 The View Policy Language 4 1.1.1 Policy 4 1.1.2 Roles 5 1.1.3 Views 7 1.2 Implicit Authorizations, Denials, and Conflict Resolution 10 1.2.1 Denials 10 1.2.2 Conflicts and Priorities 10 1.3. Thay đổi quyền tự động 13 1.3.1. Explicit Assignment: Gán khung nhìn 14 1.3.2 Implicit Assignment: Schemas 15 1.4. Điều kiện và khung nhìn ảo 16 Chương 2 18 A Discussion of the View–Based Access Model 18 2.2. A Discussion of the View–Based Access Model 18 2.2.1. Principals and Roles 18 2.2.2 A typed matrix model 19 2.2.3 Quan điểm và ma trận ràng buộc 23 2.2.4 Explicit Discretionary Assignment and Removal 23 Kết luận 25 Tài liệu tham khảo 27   DANH MỤC HÌNH ẢNH Figure 1.1: An example policy 5 Figure 1.2: Role declarations 7 Figure 1.3: A view definition. 8 Figure 1.4: The Document interface. 8 Figure 1.5: View extension. 9 Figure 1.6: Denials and explicit priorities 11 Figure 1.7: Potentially conflicting views 11 Figure 1.8: Conflict between strong rights. 12 Hình 1.9: Loại và hoạt động thừa kế 13 Figure 1.10: An assignable view. 14 Figure 1.11: Interface DocumentFactory. 15 Hình 1.12 liệt kê định nghĩa khung nhìn 16 Figure 1.13: Conditional access rights. 17 Figure 2.1: Groups and Roles 19 Figure 2.2: Role declarations. 22   Lời mở đầu Lý do chọn đề tài: Tính bảo mật: khi gán quyền cho người dùng vào một table nào đó có nghĩa người dùng có thể xem được tât cả nhũng thông tin trong table đó như địa chỉ, email, số điện thoại. vì thế tạo ra những view để ẩn những thuộc tính không cho phép truy nhập vào để đảm bảo thông tin cá nhân. Ví dụ như ngân hàng, viễn thông, thông tin cá nhân của khách hàng, thẻ thì cần che dấu đi có thể chọn giải pháp mã hóa nhưng mã hóa xong có thể bị giải mã nên tốt nhất nên chọn cách giấu nó đi, tạo ra các view che giấu một số trường trong table. Liên quan đên hiệu năng: khi người dùng truy vấn join, một số người không viết cẩn thận sẽ dẫn load các trường hợp khác nhau mặc dù kết quả đạt được như nhau nhưng tải nặng hơn. Với SQL Developer ta có thể tối ưu hóa tạo ra các view. Ngoài ra thì view còn thuận tiện cho người sử dụng thay ví viết những câu lệnh dài ta chỉ cần tạo một view và hiển thị các trường trong bảng. Đề tài gồm 2 chương: Chương 1: Giới thiệu các khái niệm và cú pháp của View Policy Language Chương 2: Thảo luận các ViewDựa truy cập mẫu Nhóm sinh viên   CHƯƠNG 1 Giới thiệu các khái niệm và cú pháp của View Policy Language 1.1 The View Policy Language Mục này giới thiệu về View Policy Language (VPL), loại chính sách được định nghĩa trong chính sách ứng dụng. Chính sách này đi kèm và triển khai cùng ứng dụng. Chương này để giới thiệu một cách tổng quan về ngôn ngữ này và cú pháp của nó. Chi tiết trong phần 2.1 1.1.1 Policy Nội dung chính sách VPL nhằm trình bày vai trò cũng như định nghĩa khung nhìn và các lược đồ. Các khái niệm này được trình bày trong phần sau. Trong VPL, chính sách kiểm soát truy cập được bắt đầu bằng từ khóa policy. Chính sách này được định nghĩa cho một đối tượng không gian dạng lưới đồng thời định nghĩa các trường ValueReader và ValueAdmin. Các hệ thống truy cập dùng để xác định kích cỡ của lưới với chiều rộng và chiều cao, hàm set(), get() trong ô lưới. Ví dụ sau về chính sách sẽ định nghĩa 2 kiểu xác thực Getting và Setting được gán cho ValueReader và ValueAdmin .

MỤC LỤC

DANH MỤC HÌNH ẢNH

Lời mở đầu

Lý do chọn đề tài:

Tính bảo mật: khi gán quyền cho người dùng vào một table nào đó có nghĩa người dùng có thể xem được tât cả nhũng thông tin trong table đó như địa chỉ, email, số điện thoại vì thế tạo ra những view để ẩn những thuộc tính không cho phép truy nhập vào để đảm bảo thông tin cá nhân Ví dụ như ngân hàng, viễn thông, thông tin cá nhân của khách hàng, thẻ thì cần che dấu đi có thể chọn giải pháp mã hóa nhưng mã hóa xong có thể bị giải mã nên tốt nhất nên chọn cách giấu

nó đi, tạo ra các view che giấu một số trường trong table

Liên quan đên hiệu năng: khi người dùng truy vấn join, một số người không viết cẩn thận sẽ dẫn load các trường hợp khác nhau mặc dù kết quả đạt được như nhau nhưng tải nặng hơn Với SQL Developer ta có thể tối ưu hóa tạo ra các view

Ngoài ra thì view còn thuận tiện cho người sử dụng thay ví viết những câu lệnh dài ta chỉ cần tạo một view và hiển thị các trường trong bảng

CHƯƠNG 1 Giới thiệu các khái niệm và cú pháp của View Policy Language

1.1 The View Policy Language

Mục này giới thiệu về View Policy Language (VPL), loại chính sách được định nghĩa trong chính sách ứng dụng Chính sách này đi kèm và triển khai cùng ứng dụng Chương này để giới thiệu một cách tổng quan về ngôn ngữ này và cú pháp của nó Chi tiết trong phần 2.1

1.1.1 Policy

Nội dung chính sách VPL nhằm trình bày vai trò cũng như định nghĩa khung nhìn và các lược đồ Các khái niệm này được trình bày trong phần sau Trong VPL,chính sách kiểm soát truy cập được bắt đầu bằng từ khóa policy Chính sách này được định nghĩa cho một đối tượng không gian dạng lưới đồng thời định nghĩa các trường ValueReader và ValueAdmin Các hệ thống truy cập dùng để xác định kích

cỡ của lưới với chiều rộng và chiều cao, hàm set(), get() trong ô lưới Ví dụ sau về chính sách sẽ định nghĩa 2 kiểu xác thực Getting và Setting được gán cho

ValueReader và ValueAdmin

Figure 1.1: An example policy

1.1.2 Roles

Role là ngôn ngữ khái niệm tập hợp các quyền được nhóm lại biểu diễn chính sách tương ứng cho UML Cú pháp VPL minh họa trong mục 1.1 Một vài ví dụ khác trong hình 1.2 trong đó định nghĩa roles của giảng viên, học sinh, giám thị trong một ví dụ giả định tại trường đai học hay một nhà xuất bản sách Các quyền trong roles nêu rõ tên và các tùy chọn, rằng buộc và các quyền ban đầu Chú thích

{

roles

ValueReader holds Getting on Grid

ValueAdmin holds Setting on Grid

view Getting controls Grid

Heads : Examiner trong 1.2 có nghĩa và Head role là một sub role của Examiner role Có nghĩa là sub role này thừa kế quyền thử super role Một role có thể có nhiều hơn một super role Một role có thể gán khung nhìn cho role khác bằng từ khóa hold Việc gán quyền khung nhìn cho đối tượng được liệt kê sau từ khóa sẽ được thực hiện khi chính sách mới được triển khai trong hệ thống , trong suốt thời gian sử dụng chính sách này, việc gán quyền cho chủ thể có thể thay đổi

Ràng buộc tối đa được định nghĩa bằng từ khóa maxcard trong đó nó được sử dụng dể hạn chế số lượng đối tượng tối đa từ President role gán cho các đối tượng khác Tương tự như vậy từ khóa mincard có thể sử dụng để chỉ ra số lượng đối tượng tối thiểu được gán cho role Từ khóa excludes chỉ ra các mối quan hệ loại trừquyền lẫn nhau giữa các role, khi đó ta phải định nghĩa ràng buộc điều kiện để giải quyết vấn đề này Trong ví dụ dưới, không đối tượng nào được gán cho Candidate

và Examiner role , Assistants phải được gán cho Secretary role Những ràng buộc này sẽ được giải thích rõ hơn trong mục 2.2.3.2

Figure 1.2: Role declarations

1.1.3 Views

Mô hình này góp phần thể hiện cái khái niệm của khung nhìn với các chính sách

có thể tự viết và hiểu được các thuật ngữ liên kết liên quan đến vấn đề xác thực Một khung nhìn là một tên của quyền truy câp, trong đó, nêu quyền cho phép hoặc

bị chặn một hoạt động trên một đối tượng Trong khi việc có được truy cập hay không phụ thuộc vào quyền cá nhân thì khung nhìn là các đơn vị hiển thị và phân quyền Ví dụ 1.3 thể hiện một ví dụ về định nghĩa khung nhìn trong VPL trong đó định nghĩa các quyền đối tương truy cập vào Document Khung nhìn được định nghĩa là giấy phép cho một đối tượng trên một IDL độc lập, trong đó nó tham chiếuđến các điều khoản kiểm soát trong định nghĩa khung nhìn Trong ví dụ, khung nhìn Reading có thể sử dụng Document( ví dụ 1.4) Có nghĩa là khung nhìn này

có thể được gán cho một đối tượng được quyền sử dụng hay các quyền thấp hơn khác Quyền được liệt kê sau từ khóa allow, quyền phủ định được sử dụng sau từ khóa deny Trong ví dụ này, chỉ có quyền sử dụng Document chỉ là quyền đọc và tìm từ khóa là được cho phép Một khung nhìn có thể bị hạn chế các roles nhất định

policy University {roles

Examiner holds ExaminingHead: Examiner // head is a sub role of examiner

President maxcard 1Lecturer

Candidate excludes Examiner}

policy Publisher {roles

StaffAuthorSecretary: StaffAssistant: Staff requires SecretaryReviewer: Staff

Editor: StaffManager: Staff}

để không thể gán khung nhìn cho ai khác trừ những người được chỉ định trong danhsách hạn chế Khung nhìn Reading có thể gán cho roles Staff, Author, và các subroles Mô hình truy cập trong VPL bản chất là một ma trận truy cập với role là các hàng, đối tượng là các cột và khung nhìn là các mục trong ma trận

Figure 1.3: A view definition.

Figure 1.4: The Document interface.

View extension

Giống như các đổi tượng khác, khung nhìn có thể định nghĩa rộng ra để có thể tái

sử dụng trong các trường hợp đặc biệt Một khung nhìn mở rộng thừa kế tất cả các quyền cơ sở, cả quyền khẳng định và phủ định, và chúng cũng có thể thêm quyền mới Tuy nhiên việc thêm quyền mới có chỉ là tăng thêm các điều khoản trong khung nhìn Khung nhìn mở rộng không thể tự định nghĩa các quyền phủ định Theo định nghĩa của khung nhìn mở rộng thì đây chỉ đơn giản là việc thêm quyền giống nhu việc bổ sung thêm giao diện và không bao giờ bỏ chúng đi Như ví dụ ,

readonly attribute string title;

void read(out string text);

void write(in string text);

void append(in string text);

void annotate(in long where, in string text);

void insert(in string text, in long where);

void delete(in long from, in long to);

void find(in string text);

};

khi principal giữ cả khung nhìn cơ bản và khung nhìn mở rộng của một đối tượng nhất định thì khung nhìn mở rộng sẽ có thể thay thế cho khung nhìn cơ bản

Figure 1.5: View extension.

Trong VPL, phần mở rộng được biểu diễn bằng cách liệt kê một tập hợp các khung nhìn cơ bản sau dấu hai chấm Như ví dụ 1.5 khung nhìn Updating là mở rộng của Appending, do đó nó thừa thế hoạt động của append và thêm các quyền

mà nó định nghĩa riêng Lưu ý là Updating không được định nghĩa quyền kiểm soát

rõ ràng mà nó chỉ ngầm định nghĩa thông qua khung nhìn mở rộng của Appending Tuy nhiên, khung nhìn mở rộng có thể tái định nghĩa bằng cách thu hẹp lại quyền kiểm soát đối tượng hoặc giới hạn role Cả hai cách thu hẹp trên đều khiến khung nhìn “ ít thay đổi” có nghĩa là chúng sử dụng để hạn chế đối tượng và roles được gán bởi việc:

+ Thu hẹp quyền kiểm soát có nghĩa là định nghĩa lại quyền kiểm soát của một subtype trong khung nhìn mở rộng

+ Thu hẹp bằng cách giới hạn role có nghĩa là mỗi role bị giới hạn phải là một subrole của role trong khung nhìn hoặc là một role mới được hạn chế trong khung nhìn

view Appending view Updating: Appending {controls Document allow

restricted_to Staff delete{ insert

allow }append}

1.2 Implicit Authorizations, Denials, and Conflict Resolution

Ủy quyền ngầm định ngụ ý là quyền của đối tượng khi nhóm được gán Ví dụ, nếu một khung nhìn “v” trên một đối tượng được gán cho một role “r”, điều này ngụ í là việc gán v cho tất cả các subrole của r Mặc dù việc này giúp cho việc xác định luật thuận tiện hơn việc gán từng quyền cho mỗi cá nhân nhưng công việc này cần phải được chú ý các ngoại lệ khi gán quyền

1.2.1 Denials

Nếu một quyền không tồn tại thì không thể sử dụng để ghi đè lên một quyền có sẵn được nên ta cần định nghĩa lại quyền phủ định hoặc từ chối Quyền từ chối không được dùng để biểu diễn các ngoại lệ, chúng được dùng để xác định các ràng buộc trong chính sách truy cập Ta có thể xem một chính sách level cao “ sinh viên bị cấm sử dụng máy in màu” Nếu chính sách truy cập không chứa bất kì quyền nào cho phép sinh viên được tiếp cận đối tượng như vậy, nghĩa là sinh viên phải tuân theo các chính sách này Một điều hiển nhiên của việc sử dụng chính sáchtruy cập này dưới dạng quyền từ chối là không cần thiết nhưng nó đem lại 2 tác dụng tích cực Thứ nhất, việc tái sử dụng lại toàn bộ chính sách ở level cao sẽ dễ dàng hơn level thấp Thứ hai, quyền từ chối có thể được giải thích như là ràng buộc

mở rộng của cấu hình mô hình truy cập và do đó nó giúp tránh các lỗi của chính sách ban đầu do quản trị viên vô ý gây ra, điều này có thể xảy ra khi quản trị viên thêm các chính sách mà họ không hiểu rõ Tuy nhiên, điều này không phù hợp với chính sách permit bởi sẽ gây xung đột giữa các chính sách, tuy nhiên mô hình này

sẽ để các xung đột tự do, thậm chí là không có trường hợp ngoại lệ nào cả Chẳng hạn như chính sách từ chối việc gán khung nhìn cho một người nếu có xung đột vớikhung nhìn có sẵn qua việc kiểm tra các ràng buộc mới

1.2.2 Conflicts and Priorities

Nếu có thể định nghĩa đồng thời quyền cho phép và từ chối, xung đột có thể xảy

ra Nhiều trường hợp xung đột xảy ra bởi các chính sách chưa đầy đủ hoặc có mâu thuẫn với nhau chứ không phải là do có trường hợp ngoại lệ gây ra Bởi vì các trường hợp ngoại lệ bản chất là các trường hợp ta dùng để giải quyết mâu thuẫn và

ta sử dụng chúng để phát hiện và giải quyết xung đột

Các giải pháp giải quyết xung đột bằng các mối quan hệ mở rộng giữa khung nhìn và quyền ưu tiên được định nghĩa trong khung nhìn Quyền ưu tiên trong mô hình có thể có một trong 2 giá trị: mạnh và yếu Trong [Rabitti et al., 1991] viết, quyền mạnh là quyền không bị quyền khác ghi đè lên trong trường hợp xung đột

Ví dụ như việc gán quyền cấm sinh viên sử dụng máy in là quyền mạnh và không

quyền nào khác có thể ghi đè lên, vì vậy không có chính sách vi phạm, và không cóxung đột

}

Figure 1.6: Denials and explicit priorities

Một ví dụ của quyền ưu tiên( ví dụ 1.6) Trong định nghĩa khung nhìn BaseView,

từ khóa strong đánh dấu quyền từ chối cho hoạt động op_3 và quyền cho phép sử dụng hoạt động “DerivedView “ cũng là “ strong”, tất cả các quyền còn lại trong khung nhìn đều yếu hơn Để kiểm soát các khung nhìn mở rộng ta cần xác định lại quyền thừa kế của khung nhìn mở rộng Một khung nhìn mở rộng có thể xác điịnh lại các quyền weak Quyền strong có thể không cần định nghĩa lại và định nghĩa DerivedView trong ví dụ 1.6 cho thấy là không phù hơp vì quyền từ chối op_3 trong BaseView không thể định nghĩa lại

Xung đột giữa quyền cho phép và từ chối của một hoạt động có thể xảy ra nếu ta

áp dụng chúng trên một đối tượng Vì một khung nhìn cho phép xung đột tự do nêntình huống này đòi hỏi người quản trị phải giữ cả hai khung nhìn A và B trên cùng một đối tượng, như trong ví dụ minh họa 1.7 Điều này có thể xảy ra ở cả 2 trường hợp, cả hai đều đòi hỏi đối tượng S và T liên quan

Figure 1.7: Potentially conflicting views

Giải quyết xung đột giữa các khung nhìn liên hệ với nhau

Trường hợp đầu tiên là khung nhìn A và B có liên quan với nhau là quan hệ mở rộng Hai khung nhìn liên quan bằng quan hệ mở rộng nếu một khung nhìn có đường dẫn trực tiếp đến khung nhìn mở rộng nằm trong cây khung nhìn khác Nếu các khung nhìn này không liên quan tới nhau, thì chỉ cần chúng có chung gốc từ một khung nhìn trường hợp này cũng xảy ra Như hình 1.7 A liên quan tới B nếu

view BaseView controls T view DerivedView: BaseView

cha của khung nhìn A là khung nhìn con của B hoặc cha của khung nhìn B là D lại

là khung nhìn con của A Trong trường hợp này, quyền của gốc được ưu tiên nếu A

ở gốc cao hơn, do đó xung đột sẽ được giải quyết theo A, ở đây đơn giản là ghi đè quyền từ chối lên B

Giải quyết xung đột khung nhìn không liên quan tới nhau

Trường hợp thứ hai là xung đột giữa 2 khung nhìn không liên quan và xung đột thể hiện qua nhiều hình thức và được hỗ trợ bởi các mô hình dữ liệu hướng đối tượng: một khung nhìn được định nghĩa để kiểm soát và kiểu con Ở đây, giải quyếtxung đột có thể dựa vào độ ưu tiên: Độ ưu tiên của quyền cho phép và từ chối xem quyền nào mạnh hơn sẽ được ưu tiên Để đảm bảo giải quyết xung đột kiểu này luôn khả thi, thì độ ưu tiên các quyền phải như nhau và không có quyền đặc biệt Ví

dụ 1.8 minh họa

Figure 1.8: Conflict between strong rights.

Ở đây ta có thể suy ra rằng cả 2 hai trường hợp, xung đột giữa hai quyền yếu hayhai quyền mạnh sẽ được giải quyết bằng một ngôn ngữ quy tắc Tuy nhiên, việckiểm tra tính đơn thuần chỉ có thể thấy được khả năng xung đột ở mức định nghĩa

và do đó thiếu trường hợp cần thiết.Nhằm giải quyết hạn chế này, chúng ta sẽ chophép xung đột giữa quyền yếu sau đó dùng quyền từ chối được ưu tiên Phươngpháp này sẽ không khả thi với 2 quyền mạnh vì nó vi phạm ngữ nghĩa các quyềnmạnh Do đó, xung đột giữa các quyền mạnh phải được phát hiện và tự giải quyếtthủ công

Với mô hình được định nghĩa bởi OMG ODL, nó có thể tự tìm ra định nghĩa khung nhìn với các quyền không phù hợp Sau một bài kiểm tra kỹ thuật thì nó có thể thể từ chối hoặc đưa ra cảnh báo nếu có hai quyền xung đột là mạnh Đối với hai không nhìn riêng biệt, xung đột giữa định nghĩa quyền chỉ xảy ra nếu 2 kiểu đốitượng như nhau, như hình 1.8 hay các ví dụ thừa kế khác Ở đây chỉ có một tình huống trong đó có hoạt động có tên i hệt nhau trong giao diện IDL Sau bài kiểm

view A controls T { view B controls

T {

allow deny strong op strong op

tra có thể phát hiện các trường hợp như vậy và trả về chính sách kỹ thuật, từ đó có thể đảm bảo các quyền ưu tiên.

T U V

U T

a) b) c)

Hình 1.9: Loại và hoạt động thừa kế

Chúng ta cần lưu ý rằng các trường hợp này có thể phát hiện bởi các ràng buộc thừa kế trong mô hình, trong đó việc ngăn chặn các hoạt động cùng tên, supetypes

có liên quan hay như trường hợp 1.9 Trường hợp này khó hiểu bởi có 2 khung nhìn không liên quan S và T được định nghĩa quyền mạnh nhưng một quyền denial mạnh cho op() vẫn có thể được gán cho các đối tượng như U bởi vì phần mở rộng chồng lấn trên U Điều này sẽ dẫn đến xung đột ngữ nghĩa của các quyền mạnh trừkhi có sử phân cấp và trường hợp c là kết quả xảy ra để đảm bảo quyền mạnh không bị ghi đè

Hạn chế này không có ở các ngôn ngữ khác tuy nhiên trong Java một class có thểthừa kế định nghĩa từ hoạt động op() từ nhiều nơi Điều này là hợp lệ bởi về nhiều quyền thừa kế được cho phép trong Java

1.3 Thay đổi quyền tự động

Trạng thái của hệ thống bảo về thường không thay đổi Đối tượng, role, và nhóm

có thể được thêm, xóa vào trong hệ thống hay khung hay hoặc cũng có thể bị xóa

đi vì lí do quản trị hay do việc phân quyền hoặc do các chính sách bảo mật Một số ngoại lệ có thể xảy ra trong trạng thái này khi một người dùng cụ thể có quyền thựchiện các thay đổi ngầm định trạng thái của hệ thống bảo vệ Cả hai thay đổi này sẽ được đề cập trong phần sau