27
MỤC LỤC
1
27
DANH MỤC HÌNH ẢNH
2
27
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 View-Dựa truy cập mẫu


Nhóm sinh viên
3
27
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 .
4
27
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
5
policy Grid
{
roles
ValueReader holds Getting on Grid
ValueAdmin holds Setting on Grid
view Getting controls Grid

{
allow
height
width
get
}
view Setting: Getting
restricted_to ValueAdmin
{
allow
set
}
}
27
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.
6
27

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
7
policy University {
roles
Examiner holds Examining
Head: Examiner // head is a sub role of
examiner
President maxcard 1
Lecturer
Candidate excludes Examiner
}
policy Publisher {
roles
Staff
Author

Secretary: Staff
Assistant: Staff requires Secretary
Reviewer: Staff
Editor: Staff
Manager: Staff
}
27
để không thể gán khung nhìn cho ai khác trừ những người được chỉ định trong danh
sá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ụ ,
8
view Reading
controls Document
restricted_to Staff, Author
{
allow
read
find
}

interface Document {
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);
};
27
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.
9
view Appending view Updating: Appending {

controls Document allow
restricted_to Staff delete
{ insert
allow }
append
}
27
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ách
truy 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ới

khung 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
10
27
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ên
tì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
11
view BaseView controls T view DerivedView: BaseView
{ {
allow allow
op_1 op_4
op_2 strong op_3 // incorrect
deny }
strong op_3
op_4
view A: C controls T { view B: D controls S {
allow // inherits a denial for
op // op from its ancestors
} }
27
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ết

xung độ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 hay
hai quyền mạnh sẽ được giải quyết bằng một ngôn ngữ quy tắc. Tuy nhiên, việc
kiể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ẽ cho
phép xung đột giữa quyền yếu sau đó dùng quyền từ chối được ưu tiên. Phương
phá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ền
mạnh. Do đó, xung đột giữa các quyền mạnh phải được phát hiện và tự giải quyết
thủ 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 đối
tượ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
12
view A controls T { view B controls
T {
allow deny
strong op strong op
27
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.
Sop() Sop() Sop() Top()

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ực
hiệ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.
13
27
1.3.1. Explicit Assignment: Gán khung nhìn
Việc thêm hay xóa khung nhìn từ một ma trận truy cập có thể có những hậu quả
nghiêm trọng do đó để làm được việc này cần có quyền đặc biệt. Các quyền này
thường được trao cho các nhà quản lý chính sách, người có trách nhiệm theo dõi
các chính sách và đôi khi cần chỉnh sửa chúng cho các hoàn cảnh cụ thể như ủy
quyền cho môt role. Nếu một role cần quyền để thực hiện tác vụ thì chúng nên

được ủy quyền, người quản lý cần thêm các khung nhìn khung nhìn cần thiết cho
role.
Loại hình thứ hai của việc gán hay xóa khung nhìn để chúng không bị người
quản trị hạn chế là các chính sách liên quan đến DAC (Discretionary Access
Control). Nó xảy ra khi một principal gán hay xóa một hoạt động trên ma trận truy
cập nhằm có thể sử dụng khung nhìn của một principal khác. Cho tới giờ, principal
vẫn chỉ là role nhưng với gán quyền truy cập thì cần thiết cho cả các đối tối tượng
cá nhân như là principal chứ không phải là toàn bộ role.
Khung nhìn có thể được sử dụng nếu định nghĩa của chúng cho phép được
chuyển nhượng. Để cho phép điều này, việc gán khung nhìn cho PublicReviewing
trong ví dụ 1.10 được đánh dấu là có thể chuyển nhưọng được. Trong ví dụ khung
nhìn PublicReviewing ban đầu có thể gán quyền cho Reviewer role, nhưng đối
tượng của role này cũng có thể tự do sử dụng khung nhìn này để gán quyền bên
ngoài. Hoạt động này được cho phép bởi hàm annotate(), read() và find(). Hai
quyền cuối được thừa kế từ khung nhìn Reading. Ngoài ra chúng cũng được thừa
kế kiểm soát Document.Hạn chế của các role này là chúng bị thu hẹp trong Staff và
bị ngăn từ principal được phép gán quyền khung nhìn PulicReviewing cho các role
khác hay subrole,
Figure 1.10: An assignable view.
Mặc định thì khung nhìn không thể được gán và nếu không được thêm vào trong
định nghĩa khung nhìn thì chúng không được quyền gán. Không như hạn chế của
role hay các type kiểm soát.
14
assignable view PublicReviewing: Reading // on Documents
restricted_to Staff
{
allow
annotate
27
1.3.2 Implicit Assignment: Schemas

Thuật ngữ implicit assignment của khung nhìn đề cập đến những thay đổi trong
trạng thái bảo vệ trong ma trận. Những thay đổi này của quyền là đặc biệt quan
trọng nhằm thể hiện chính sách như Chinese Wall. Những sự kiện cần chú ý ở đây
là các hoạt động gọi, chuyển nhượng đều được tự động.
Như ví dụ mô tả dưới đây chỉ ra làm thế nào để một chủ sở hữu có thể được gán
bởi một đối tượng bằng hàm creat(trong ví dụ này IDL của DocumentFactory được
sử dụng
Figure 1.11: Interface DocumentFactory.
Ví dụ 1.12 liệt kê định nghĩa khung nhìn Managing trong đó khung nhìn Update
trong đối đượng Document được thêm quyền copy hoặc xóa tài liệu và nó được
chuyển cho principal khác. Bởi vì khung nhìn này dựa trên khung nhìn mở rộng
Appending nên quyền của khung nhìn này bị giới hạn cho role Staff và subrole.
Khung nhìn Creating cho phép việc creat() trên đối tượng DocumentFactory.
15
interface DocumentFactory {
Document create();
};
27
Figure 1.12: Views and schema for document creation.
Hình 1.12 liệt kê định nghĩa khung nhìn
1.4. Điều kiện và khung nhìn ảo
Việc thể hiện quyền truy cập một cách mềm dẻo phụ thuộc vào sự kết hợp của
khung nhìn, một điều khoản mới cho khung nhìn được giới thiệu ở đây. Trong ví
dụ 1.13 một đối tượng giữ khung nhìn SafeOpening vẫn không đủ an toàn khi mở
Principal muốn có các khung nhìn khác. FirstKey, SecondKey, ThirdKey. Những
khung nhìn được khai báo là ảo và không bó phần thân(bodies). Khung nhìn ảo chỉ
là một khung nhìn mà không có phần bodies. Lưu ý rằng một khung nhìn bình
thường không hẳn là một khung nhìn ảo.
16
assignable view Managing: Updating {

allow
copy
destroy
}
view Creating controls DocumentFactory {
allow
create
}
schema DocumentManaging
observes DocumentFactory
{
create
assigns
PublicReviewing on result to caller
with assign option
assigns
Managing on result to caller
with assign option
removes
Creating on this from caller
}
27
Figure 1.13: Conditional access rights.
Bằng việc khai báo một khung nhìn ảo, các hoạt động thực tế được tách rời khỏi
quyền truy cập, một khung nhìn ảo không đề cập đến các hoạt động, nó chỉ có chức
năng duy nhất là cho phép nhận thực kết hợp với khung nhìn khác. Trong ví dụ
1.13 khung nhìn SecondKey không có quyền kiểm soát và do đó nó có thể được
gán cho một đối tượng bất kỳ. Tuy nhiên nó vẫn có thể sử dụng để định nghĩa
quyền kiểm soát cho các mục đích khác, do đó khung nhìn ảo vẫn cần các điều
khoản kiểm soát.

Bằng việc khai báo một khung nhìn ảo, các hoạt động thực tế được tách rời khỏi
quyền truy cập, một khung nhìn ảo không đề cập đến các hoạt động, nó chỉ có chức
năng duy nhất là cho phép nhận thực kết hợp với khung nhìn khác. Trong ví dụ
1.13 khung nhìn SecondKey không có quyền kiểm soát và do đó nó có thể được
gán cho một đối tượng bất kỳ. Tuy nhiên nó vẫn có thể sử dụng để định nghĩa
quyền kiểm soát cho các mục đích khác, do đó khung nhìn ảo vẫn cần các điều
khoản kiểm soát.
17
view SafeOpening
controls Safe
requires FirstKey, SecondKey, ThirdKey
{
allow
open
}
virtual assignable view FirstKey
controls Safe
restricted_to KeyHolder
virtual assignable view SecondKey
restricted_to KeyHolder
virtual assignable view ThirdKey
controls Safe
restricted_to KeyHolder
27
Chương 2
A Discussion of the View–Based Access Model
2.2. A Discussion of the View–Based Access Model
2.2.1. Principals and Roles
Như đã nói trong mục 1.1, principal từng được dùng để gọi một role- 2 tính năng
này tương tác với nhau. Với góc nhìn của nhà phát triển, role là tập hợp mang tính

trừu tượng từ người dùng cá nhân gọi đến, trong đó thời gian phát triển hoàn toàn
không được chú ý.
Hạn chế của việc chuyển nhượng quyền cho một role là việc kiểm soát truy nhập
tùy ý trong mục 1.3.1. Vì vậy ở đây chỉ đề cập tới các vấn đề cá nhân, hướng đối
tượng như role.
Subject là một thực thể hoạt động có thể yêu cầu từ một đối tượng với các
thiếtlập thông tin của riêng mình bao gồm các thông tin riêng. Trong một hệ thống,
các thực thể ban đầu có thể yêu cầu các tiến trình sao cho subject là một trạng hai
tiến trình được nhận dạng chăng hạn như dịch vụ tên. Sử dụng thuật ngữ của
Lampson một lần nữa cho ta thấy form của yêu cầu này có dạng như “C says S say
request”, trong đó C là kênh truyền và S là subject. Nếu người nhân yêu cầu có thể
xác thực kênh truyền phát cho subject C=> S, có thể chấp nhận yêu cầu từ S.
Subject có tạo trực tiếp các yêu cầu trên kênh truyền vì subject được quyền tạo
kênh truyền và tự phát cho chính nó, điều mà một role không thể làm được. Role
cũng chỉ có thể tạo yêu cầu ở dạng liên kết với subject đã được xác thực để phát
cho role. Dạng của request được tạo bởi kênh truyền cho principal là: “C says (S as r1
^ ::: ^ rn) says request”. Trong đó S là subject và r là role. Người nhận yêu cầu cần
xác thực và S là một thành viên của role bằng cách kiểm tra S ) r1 ^ ::: ^ S ) rn. Với
các yêu cầu của cá nhân, một subject có thể có quyền chọn nếu và cho role nào mà
nó muốn phát, do đó nó có thể chọn trong các role để phát. Các role là các subject’s
active roles cho mục đích truy cập.
Roles
Role được ẩn trong cả chính sách ứng dụng và quản lý. Mô hình của role định
nghĩa mục đích không được giới thiệu ở đây.
18
27
Principal
Name: string

GroupAssignment RoleAssignment


isSubGroupOf isSubRoleOf
Figure 2.1: Groups and Roles
Để kiểm soát thông tin role được bổ sung cho group. Group không phải là
principal, nói đúng hơn thì chúng được sử dụng để gán quyền subject cho role và
tổ chức các nhóm con.
2.2.2 A typed matrix model
Để giải thích một cách chi tiết các khai niệm VPL,thì ta cần tham khảo các mô
hình truy cập cơ bản. Các cô hình truy cập được đề xuất ở đây dựa trên mô hình
truy cập cập của Lampson. Ma trận trong bảng 2.1 thể hiện trạng thái bảo vệ với
các tùy chọn ủy quyền và miêu trả các truy cập đực phép và bị cấm.
19
group
Role
subject
27

Object
Principal
F: foder Chương: tài liệu Hợp đồng: tài
liệu
Thư ký Lookup Reading Reading
Tác gỉa Lookup
Appending
Reading
Udating
Reading
Bên tập viên Liệt kê
Appending
Loại bỏ

Reading Reading
Người quản lý Lookup Reading Updating
Reviewer Lookup Reading
publicReviewing
Paul Reading
Ringo Reading
publicReviewing
Table 2.1: An access matrix with views.
2.2.3.1 Classifying Constraints
Bình thường thì các ràng buộc sẽ được phân thành động hoặc tĩnh dựa trên thời
gian ràng buộc được kiểm tra. Ràng buộc tĩnh được kiểm tra khi việc ủy quyền
được gán, ràng buộc động thì áp dụng khi truy truy cập được thực hiện. Sự khác
biệt giữa ràng buộc tĩnh và động không phù hợp với các ràng buộc trong mô hình
này vì các yếu tố trong vòng đời mô hình có nhiều hơn 2 giai đoạn. Hơn nữa thuật
ngữ “tĩnh” chỉ thấy ràng buộc không được kiểm tra khi hệ thống chạy, đó là một
vấn đề sai lầm. Ràng buộc tĩnh thực sự độc lập với thời gian ứng dụng chạy nhưng
chúng cũng thực hiện tại thời gian chạy. Do đó nó có những hạn chế:
1. Định nghĩa ràng buộc là ngôn ngữ luật về việc hạn chế tập hợp các khái niệm
được sử dụng cho các chính sách kỹ thuật cá nhân như role, khung nhìn,
object. Ràng buộc trong class này bao gồn các quy tắc cú pháp và ngữ nghĩa
được kiểm tra bằng trình biên dịch và các công cụ ngôn ngữ khác.
2. Cấu hình ràng buộc được kiểm tra trong các hoạt động nghĩa là thay đổi cấu
hình của mô hình truy cập… như chính sách. Các hoạt động này có thể là
20
27
hoạt động của admin hoặc là các thay đổi ngầm xảy ra trong suốt vòng đời
của ứng dụng.
3. Ràng buộc hoạt động áp dụng lại thời gian truy cập được thực hiện. Ví dụ
như việc kiểm tra sự hiện diện của một khung nhìn trước khi sử dụng chúng.
2.2.3.2 Principal Constraints

Các khái niệm chính mà một nguyên tắc trong mô hình của chúng tôi có đề cập
đến là những vai trò và đối tượng. Bởi vì nhóm không phải là yếu tố cơ bản,
nguyên tắc có thể không làm cho các giả định về chúng và cũng có thể không xác
định hạn chế trên các nhóm và các mối quan hệ của chúng với vai trò và đối tượng.
điều này không nhằm thể hiện rằng ràng buộc nhóm có thể không hữu ích trong bối
cảnh quản lý chính. Ví dụ, một quản lý chính có thể muốn đảm bảo rằng một cá
nhân bị loại khỏi một nhóm không bao giờ có thể trở thành một thành viên của
nhóm đó một lần nữa, vì vậy một cơ chế loại trừ có thể được xác định để ngăn chặn
sự xác nhập của đối tượng vào nhóm. Tuy nhiên, khía cạnh này của quản lý chính
được coi là một phần của mô hình của môi trường tổ chức hóa của một chính sách
hơn là một phần của định nghĩa về chính sách truy cập ứng dụng. Ràng buộc nhóm
do đó không được thảo luận ở đây.
Ràng buộc tiềm năng về các đối tượng là loại trừ đối tượng để ngăn cản hai đối
tượng từ được phân công vai trò đến đối tượng loại trừ vai trò tương tự cái mà ngăn
chặn một đối tượng cụ thể khỏi việc được giao cho một vai trò cụ thể. Tuy nhiên,
cách tiếp cận chung cho mô hình nguyên tắc ở đây là tóm tắt của các đối tượng cá
nhân vì chúng chưa được làm rõ trong quy tắc phát triển trong quá trình và trước
khi triển khai. Chính sách vì thế không dựa vào quy tắc mà tham khảo cho các đối
tượng cụ thể. Đối với lý do tương tự như với các nhóm, đó là việc thể hiện đối
tượng ràng buộc cho các mục đích quản lý chính có thể trở nên hữu ích, nhưng đây
là những không được coi là một phần của các nguyên tắc truy cập.
Các mô hình vai trò trong [Sandhu et al., 1996] định nghĩa ba loại ràng buộc làm
hạn chế sự phân công vai trò cho các đối tượng. Đầu tiên, các ràng buộc lực lượng
được giới thiệu như là các vị từ trên số lượng các đối tượng mà có thể được giao
cho một vai trò. Ví dụ, một lực lượng tối đa có thể được định nghĩa với một vai trò
đặc biệt để ngăn chặn sự phân công vai trò cho nhiều hơn một đối tượng. Trong khi
các vị tùy ý trên lực lượng là có thể, chúng tôi giới hạn thảo luận này để hạn chế tối
thiểu ràng buộc lực lượng và hạn chế tối đa ràng buộc lực lượng vì cách này được
coi là hữu ích nhất. Ví dụ, hạn chế tối thiểu ràng buộc lực lượng có thể được sử
21

27
dụng để bày tỏ rằng một vai trò nhất định phải luôn luôn có ít nhất một chủ đề được
gán cho nó - hoặc ít nhất là mười, như trong hình 2.2.
Figure 2.2: Role declarations.
Ràng buộc thứ hai là ràng buộc tiên quyết giữa các vai trò nhằm ngăn chặn sự
phân công vai trò cho một đối tượng mà đối tượng này cũng không được gán cho
một vai trò khác, ví dụ, vai trò kĩ sư kiểm tra có thể chọn bất kỳ đối tượng nào để
đảm nhiệm vai trò Thành viên dự án. Trong khi đó ảnh hưởng của rằng buộc này
đối với các nhiệm vụ và ủy quyền của đối tượng như thể kĩ sư kiểm tra là một trợ lý
hỗ trợ Thành viên dự án, ràng buộc này thúc đẩy các đối tượng được gán cho cả vai
trò cá nhân và vai trò theo một thứ tự được xác định trước.
Ràng buộc cuối cùng được đề cập trong [Sandhu et al., 1996] là loại trừ lẫn
nhau, có nghĩa là một chủ đề không bao giờ có thể được giao cho hai vai trò loại trừ
lẫn nhau cùng một lúc. Ràng buộc có thể được sử dụng để thể hiện sự tách biệt của
các yêu cầu nhiêm vụ, ví dụ, một kĩ sư kiểm tra có thể không còn là một nhà phát
triển, cả ba loại ràng buộc được thông qua bằng cách sử dụng cú pháp được giới
thiệu trong phần 1.1.2. Tất cả ba loại ràng buộc, nếu được sử dụng trong một định
nghĩa về quy tắc, được thực thi bởi các thành phần quản lý vai trò của một cơ sở hạ
tầng tổng thể, chứ không phải bởi một cơ chế truy cập kiểm soát. Thực thi được
thực hiện tại thời điểm quản lý giao nhiệm vụ cho các đối tượng.
Cần lưu ý một lần nữa rằng những người ủy nhiệm nói chung đều chịu sự kiểm
soát của một vai trò quản lý khác hơn là chính sách quản lý. Như vậy, một chính
sách truy cập hoặc là phải dựa vào các nhà quản lý chính để thực thi một cách
chính xác những ràng buộc cho người ủy nhiêm hoặc nhiều lần tái xác nhận những
ràng buộc của nó. Các ràng buộc vai trò kiểm tra ở đây thường được thực thi bằng
cách kiểm tra mọi hoạt động có thể thay đổi bất kỳ cấu trúc dữ liệu liên quan, ví dụ,
đối tượng để gán vai trò (thông qua các nhóm) hoặc thêm một mới một ràng buộc
cho các đối tượng và vai trò sẵn có. Những ràng buộc này là do ràng buộc về cấu
hình.
22

roles
ProjectMember
Developer: ProjectMember mincard 10
TestEngineer requires ProjectMember excludes Developer
27
Cả hai ràng buộc loại trừ và ràng buộc điều kiện tiên quyết có thể được lần lượt
kiểm tra khi một người ủy quyền cố gắng truy cập một đối tượng, ví dụ, như ràng
buộc về hoạt động. Một ràng buộc loại trừ hoạt động sau đó có thể được sử dụng để
thực hiện việc phân tách các nhiệm vụ. Một ràng buộc hoạt động của điều kiện tiên
quyết sẽ thi hành điều đó một vai trò nhất định chỉ được sử dụng như một yếu tố
của một số người ủy quyền và cùng với một số cần thiết khác. Đối với lý do thiết
kế ngôn ngữ, những ràng buộc hoạt động trơn tru hơn không được bao gồm trong
mô hình này. Xác định cú pháp cho cả hai ràng buộc cấu hình và hoạt động đòi hỏi
các từ khóa bổ sung và cũng đòi hỏi các nhà thiết kế phải hiểu sự phân biệt giữa hai
loại và điều kiện tiên quyết. Để làm cho ngôn ngữ đơn giản, chỉ ràng buộc cấu hình
được thông qua.
2.2.3 Quan điểm và ma trận ràng buộc
Việc giới thiệu các quan điểm như là một khái niệm ngôn ngữ được thúc đẩy bởi
các quan sát cho thấy quyền chung như "đọc", "viết", và "thực thi" là không đủ để
mô tả sự ủy quyền trong các hệ thống quy mô lớn bao gồm các đối tượng đánh
máy. Quyền chung hoặc chưa phiên dịch rất đơn giản và linh hoạt, nhưng chúng
không đủ cho các chính sách truy cập ở cấp ứng dụng trong hệ thống đối tượng quy
mô lớn vì chúng không thể hiện cấu trúc bên ngoài cũng như ngữ nghĩa vốn có.
Quyền chung rất khó để quản lý vì nó không cung cấp bất cứ cách nào để áp đặt
các cấu trúc bên ngoài bằng cách định nghĩa các mối quan hệ hay ràng buộc. Các
gia đình quyền được giới thiệu bởi các dịch vụ an ninh CORBA là một nỗ lực nhằm
cung cấp các cấu trúc bằng việc nhóm quyền lại, nhưng cấu trúc này không thực sự
cung cấp một cơ chế trừu tượng hữu ích có thể hỗ trợ quản lý quyền, ví dụ, quan hệ
giữa gia đình quyền. Quản lý số lượng lớn các quyền mà không dùng bất kỳ sự trừu
tượng hóa sẽ sớm làm nó trở nên chậm chạp

2.2.4 Explicit Discretionary Assignment and Removal
Một khai niệm khác là khái niệm phân cấp trong hệ thống. Ủy thác quyền nghĩa
là một ai đó chịu trách nhiệm trong vấn đề giao quyền chẳng hạn như
administrator, cho phép một ai đó có quyền gán các quyền con. Thôn thường việc
này được phân cấp và phân chia theo mục đích sử dụng. Nếu người được ủy quyền
rời khỏi vòng tròn bổ nhiệm của nhà quản trị và truyền quyền lại cho người dung
thông thường, nó gọi là kiểm soát truy cập tùy ý, việc gán quyền trái với ý muốn
của người sử dụng quyền.
Trong nhiều hệ thống, khai niệm quyền sở hữu tài nguyên hệ thống được sử
dụng cho các người dùng có đặc quyền này. Trong hệ thống UNIX, người tạo ra
23
27
file đồng thời là người sỡ hữu có quyền gán hay xóa quyền trên 1 file cho người
khác. Ngòài ra chủ sở hữu có thể bỏ quyền sở hữu một file cho các user khác, và
có thể là người sở hữu duy nhất cho bất kì người nào.
Tương tự như vậy, người tạo bảng dữ liệu trong SQL trở thành chủ sở hữu của
bảng và có thể gán quyền cho các principal khác. Ngoài ra, không chỉ là cấp quyền,
chủ sơ hữu còn có thể gán quyền với các tùy chọn gán quyền.Một người được cấp
quyền với các tùy chọn gán quyền có thể có quyền được gán quyền cho principal.
Trong trường hợp này, có rất nhiều khả năng cấp quyền, mặc dù chỉ có một nguồn.
Ngoài ra nếu quyền được gán với số lượng lớn người dùng việc thu hồi hồi có thể
dẫn đến thu hồi theo tầng.
24
27
Kết luận
Khung nhìn Views là tập hợp động của một hoặc nhiều quan hệ cơ sở (base
table) để sinh ra một quan hệ khác. Views được hiểu như một khung nhìn, nó giúp
cho người dùng có cái nhìn tổng quan hơn về dữ liệu trên 1 hoặc nhiều bảng. Nó đc
hiểu như là 1 bảng ảo, nó không tồn tại thực trong CSDL .Dưới đây là các thuận lợi
và bất lợi khi sử dụng View:

Thuận lợi:
- Độc lập dữ liệu: Một View giúp thể hiện một bức tranh nhất quán, không thay đổi
về cấu trúc của CSDL, thậm chí khi các bảng nguồn thay đổi cấu trúc (thêm, bớt
trường ).
- Tính mới nhất : Mọi sự thay đổi dữ liệu trong bảng đều được cập nhập trên khung
nhìn View.
- Bảo mật: Nếu 1 người dùng được cung cấp truy cập CSDL thông qua 1 tập nhỏ
các View chưa dữ liệu thích hợp thì giới hạn và quản lý sự truy cập của người dùng
vào CSDL tốt hơn.
- Giảm sự phức tạp: View làm đơn giản hóa câu lệnh truy vấn, thay vì select dữ liệu
từ nhiều bảng (Join hay Sub Query) thì người dùng chỉ cần select dữ liệu từ một
bảng ảo này. Và dữ liệu này sau đó được xử lý đi xử lý lại nhiều lần trước khi lên
một loại báo cáo tổng hợp với nhiều cách tổng hợp (theo ngày, theo đơn vị thực
hiện, theo người dùng ) : ).
- Thuận tiện: Views giúp người dùng có cái nhìn tổng quan hơn. Thay vì một loạt
dữ liệu lằng nhằng từ các bảng thì với Views họ sẽ thấy được những mảng dữ liệu
mà họ cần tới thôi.
- Khả năng tùy biến: có thể tùy biến, thêm trường, bớt trường mà mình muốn thể
hiện trên Views.
- Toàn vẹn dữ liệu
+ Bất lợi:
Hạn chế cấu trúc: Cấu trúc của View được xác định tại thời điểm nó tạo ra. Giả
sử bạn tạo View với câu lệnh Select * from tblTemp thì Views sẽ lấy tất cả các cột.
Nhưng khi bảng này thêm được thêm mới 1 cột thì cột này không hiển thị trên
Views. Trừ khi bạn drop đi và tạo lại Views.
- Hiệu quả hoạt động : Trong 1 số trường hợp thì thực thi câu lệnh truy vấn từ View
, thời gian truy vấn không thành vấn đề khi cấu trúc dữ liệu nhỏ hoặc độ rộng các
Object không quá lớn. Nó không đáng kể so với select từ bảng thật. Nhưng với một
25