XẾP LOẠI CHÍNH SÁCH BẢO MẬT TRONG SQL

Trang 1
XẾP LOẠI CHÍNH SÁCH BẢO MẬT TRONG SQL
Tóm tắt
Chúng tôi tìm cách hiển thị nhiều chính sách kiểm soát truy nhập dựa trên quy định chính
thức của các nhóm phân tầng của khoản logic hình thức. Sau đó chúng tôi tìm cách hiểm
thị các thông số kỹ thuật chính thức có thể được tự động dịch sang một tập con nhỏ của
SQL được sử dụng để liên tục bảo vệ một CSDL quan hệ từ các yêu cầu đọc trái phép và
cập nhật được chứng thực bởi người dùng thực hiện. Chúng tôi chứng tỏ sức mạnh của
cách tiếp cận của chúng tôi bằng cách tìm cách hiển thị một loạt các chính sách
truy cập đại diện có thể được kiểm soát.
1.Giới thiệu
Trong các tiêu chuẩn SQL2 [6], các tính năng ngôn ngữ bảo mật cụ
thể đề xuất để bảo vệ dữ liệu trong một cơ sở dữ liệu quan hệ
hạn chế đến CẤP đơn giản và thu hồi báo cáo (mặc dù quan điểm
cũng có thể được sử dụng để giúp cung cấp bảo mật). Mô hình CẤP
thu hồi cho phép một quản trị viên an ninh chỉ để đại diện cho một
nhóm nhỏ của các chính sách kiểm soát ứng dụng cụ thể truy cập cần
thiết trong thực tế; SQL không cho phép các chính sách mở [5] được
thể hiện (ví dụ,bất cứ điều gì không rõ ràng cấm được phép) cũng
không thể áp đặt các hạn chế về việc sử dụng một đặc quyền cấp
[16].
Ngày nay, nhiều tổ chức đang sử dụng điều khiển truy cập dựa trên
vai trò (RBAC) chính sách [10]. Trong RBAC, người dùng được giao
với vai trò trong một tổ chức trên cơ sở (thông thường) của trình độ và
chuyên môn của họ, và cho phép truy cập chức năng hoặc các đối
tượng trong cơ sở dữ liệu và máy chủ khác được giao cho những vai
trò này. Bằng cách chỉ định các điều khoản trên các đối tượng với vai
trò thay vì trực tiếp đến người dùng cá nhân, như trường hợp với
chính sách truyền thống, RBAC giúp đơn giản hóa đặc điểm kỹ thuật
và quản lý an ninh cơ sở dữ liệu.
Trong khi RDBMS sản phẩm và tiêu chuẩn SQL3 bao gồm một số hỗ

trợ cho vai trò, vẫn còn nhiều quan trọng chính sách sản phẩm hiện có
và SQL không thể diễn tả. Để có được nhiều quyền lực hơn ý nghĩa,
các chương trình ứng dụng được typ-ically sử dụng. Tuy nhiên, cách
tiếp cận này làm phức tạp việc duy trì một chính sách kiểm soát truy
cập và gây khó khăn cho các người quản trị an ninh đến lý do về hành
vi của họ. Do đó chúng tôi dự tính sử dụng làm của một chính sách
cấp cao đặc tả ngôn ngữ, khoản logic hình thức [12], cho phép một
loạt các chính sách kiểm soát truy cập vào được xây dựng một cách
đơn giản, và có thể được dịch ra một thực hiện chính sách sử dụng
SQL điểm (bao gồm cả đệ quy views) và gây nên. Hơn nữa, chúng tôi
nhằm mục đích cho các ranslation t từ đặc điểm kỹ thuật để thực hiện
được tự động giao phối, có lẽ ngoại trừ cung cấp các gợi ý thực hiện
mà không ảnh hưởng đến tính chính xác của việc thực hiện. Cách tiếp
cận chúng tôi mô tả làm cho nó có thể hỗ trợ một loạt các chính sách
trong bất kỳ sản phẩm quan hệ đó thực hiện các truy vấn hợp lý mạnh
mẽ như SQL2 cơ bản cộng với một VỚI tuyên bố đệ quy và gây ra
(như là đề xuất để đưa vào SQL3). Với phương pháp này, người ta có
thể đại diện cho một loạt các chính sách kiểm soát truy cập mà không
cần phải sử dụng hoặc mã ứng dụng hoặc các ngôn ngữ truy vấn cấu
trúc an ninh. (Các thiếu sót sau có thể được đặc biệt có lợi nếu có một
cách tiếp cận để thích ứng với XML thay vì cơ sở dữ liệu SQL;
XQuery cung cấp một số đệ quy và làm tổ nhưng không Grant / Thu
hồi). Một vấn đề với việc sử dụng Grant / Thu hồi và an ninh xem là
các điều khiển truy cập được biểu diễn trong hai cách riêng biệt (tài
trợ và định nghĩa xem), nên rất khó để lý do về hiệu ứng ròng của họ.
Trong cách tiếp cận của chúng tôi quy luật của logic được khai thác để
làm cho nó dễ hiểu hơn đại diện chính sách. Một mục tiêu tiếp tục
công việc của chúng tôi là để chỉ ra cách tiếp cận chính sách kiểm
soát có thể được biểu diễn trong một chính thức được xác định rõ
Bằng cách đó, nhưng mà không yêu cầu các học viên có một sự hiểu

biết phát triển của các khái niệm kỹ thuật mà chúng tôi phương pháp
tiếp cận dựa vào. Để đạt được mục tiêu thứ hai, ảnh minh hoạ được
sử dụng để giúp người quản trị hệ thống để xác định điều khiển truy
cập chính sách mà họ muốn thực hiện. Phức tạp của cú pháp SQL
làm cho nó khó xử để cung cấp các công cụ để từng bước chỉnh sửa
chính sách. Trong cách tiếp cận của chúng tôi, chức năng miễn phí,
phân tầng khoản logic [2] được sử dụng để xây dựng chính sách bảo
mật RBAC xác địnhtập hợp các hành động có thẩm quyền có thể
được thực hiện trên cơ sở dữ liệu. Chúng tôi tin rằng thực tế hầu hết
các chính sách an ninh có thể được thể hiện trong tập hợp con của
logic hình thức khoản. Trong khi chúng tôi nhận ra rằng các ngôn ngữ
khác có thể được dùng để xác định chính sách bảo mật, chúng tôi tin
rằng có một số lý do tốt để xây dựng chính sách an ninh là điều khoản
phân tầng hình thức lý thuyết. Ví dụ, khoản logic phân tầng (có nguồn
gốc trực tiếp từ các cấu trúc giao diện trình bày cho người sử dụng)
có thể đại diện cho một loạt các yêu cầu an ninh trong một ngôn ngữ
khai báo rất cao cấp. Một số nhỏ các khoản có thể thể hiện chính sách
kiểm soát truy cập thực tế, đại diện cho các chính sách trực tiếp trong
SQL là khó khăn hơn nhiều. Succinctness và đều đặn làm cho các cú
pháp lý và bảo trì dễ dàng hơn. Giống như SQL, logic này có được
xác định và uncon-troversial ngữ nghĩa mô hình lý thuyết (mô hình
ngữ nghĩa hoàn hảo [15]). Tài sản của một chính sách kiểm soát truy
cập có thể được chứng minh, cả hai trước khi thực hiện và do kiểm
toán viên . Ví dụ, một bằng chứng rằng các chính sách không cho
phép bất kỳ yêu cầu truy cập trái phép sẽ được thực hiện là một hậu
quả trực tiếp của tính đúng đắn của các tính toán phương pháp được
sử dụng trong SQL để tính toán mô hình ngữ nghĩa hoàn hảo của một
cơ sở dữ liệu quan hệ. Cuối cùng, phân tầng logic có bảo quản đơn
giản tương đương dịch sang SQL [1]. Hơn nữa, bản dịch của các điều
khoản thể hiện trong phân tầng logic vào SQL có thể được tự động.

Có chắc chắn các tùy chọn tính toán đến một trong những chúng tôi
đề xuất, ví dụ, bằng cách sử dụng một động cơ logic, lai của
SQL và logic, và thậm chí cả các bộ phận thực hiện hiệu quả cao
trong C + +. Tuy nhiên, có một số lý do tại sao phương pháp dịch thuật
có vẻ như đáng điều tra. Nó là tự nhiên để xem xét việc quản lý hệ
thống ủy quyền cho một quan hệ bằng cách sử dụng cơ sở dữ liệu
quan hệ và SQL. Nó là hấp dẫn để thực hiện chỉ SQL, thay vì thêm
một thi logic động cơ. Nó là hấp dẫn để cung cấp an ninh và bảo vệ
cho dữ liệu giao dịch chính sách bảo mật bằng cách sử dụng các
DBMS thông thường cơ sở vật chất. Cuối cùng, bằng cách tránh các
hệ thống phần mềm bổ sung (ngoài các dịch), chúng tôi tránh yêu cầu
các chuyên gia để quản lý và duy trì chúng. Các mô hình RBAC bảo
mật mà chúng tôi chỉ định trong điều khoản logic thông thường được
dựa trên những gia đình của các mô hình được mô tả trong[17]. Đó là,
chúng tôi giả định rằng một lý thuyết RBAC bao gồm vai trò và sự cho
phép tập (the
RB
AC0 model), và thêm vào đó có thể bao gồm thông số
kỹ thuật của một trong hai vai trò phân cấp (
RB
AC1) và một số loại ràng
buộc (
RB
AC2). RBAC3 subsumes
RB
AC
and
RBAC2 và do đó vai trò hỗ trợ cả
hai hệ thống thứ bậc và các loại ràng buộc men-ioned trong [17].Từ
nay trở đi bất kỳ tài liệu tham khảo cho SQL và cơ sở dữ liệu cần

được, tương ứng, hiểu là đề cập đến SQL2 (cộng với một
VỚI đệ quy xây dựng và kích hoạt) và cơ sở dữ liệu quan hệ. Trong
phần tiếp theo, chúng tôi sẽ sử dụng kiểu chữ hoa đậm để chỉ ra các
từ dành riêng của SQL và chữ thường nghiêng loại thông tin người
dùng cung cấp trong câu lệnh SQL. Phần còn lại của bài báo này
được tổ chức như vậy. Trong phần 2, chúng tôi cung cấp một giới
thiệu cơ bản để các cú pháp của bình thường khoản logic (với sự
nhấn mạnh đặc biệt vào các nhóm phân tầng), và thảo luận về một số
khái niệm có liên quan từ cơ sở dữ liệu và an ninh lý thuyết. Trong
phần 3, chúng tôi mô tả việc xây dựng một generic
RB
AC
1
security mô
hình lý thuyết được thể hiện bằng logic khoản phân tầng. Trong phần
4, chúng tôi hiển thị như thế nào dưới hình thức đại diện cho khoản
RB
AC
1
security . lý thuyết có thể được dịch sang SQL thẳng thắn và
được sử dụng để kiểm soát truy cập vào cơ sở dữ liệu. Trong Phần 5,
chúng tôi chứng minh sức mạnh của phương pháp tiếp cận của chúng
tôi bằng cách hiển thị như thế nào một loạt các chính sách kiểm soát
truy cập có thể được thể hiện trong một tập hợp con nhỏ
SQL. Trong phần 6, chúng tôi tiếp tục mở rộng đại diện của chúng tôi
của
RB
AC
1
models trong logic hình thức điều khoản và SQL để bao gồm

các ràng buộc trên
RB
AC
3
security lý thuyết, và chúng tôi xem xét việc
thực hiện những khó khăn này. Trong phần 7, một số kết luận được
rút ra và đề xuất cho việc tiếp tục được thực hiện.
2. Chuẩn
hạn chế onRBAC3security lý thuyết, và chúng tôi xem xét việc thực hiện
những khó khăn này. Trong 7 mục, một số SQL. Trong phần 6, chúng tôi tiếp
tục mở rộng ofRBAC1models đại diện trong logic hình thức điều khoản và
SQL của chúng tôi bao gồm thất bại [19], và sự phủ định của nguyên tử A
được ký hiệu là không A. Một lý thuyết thông thường là một tập hợp hữu hạn
các khoản bình thường. Kết luận được rút ra và đề xuất cho việc tiếp tục được
thực hiện. RBAC lý thuyết an ninh có thể được chính thức quy định tại một
tập hợp các chức năng logic khoản phí bình thường. Một điều khoản bình
thường một biểu hiện của các hình thức sau đây: H L1, L2 , , Lm (m 0).
Người đứng đầu của điều khoản, H, là một nguyên tử và L1, L2 , , Lm
quan hệ bằng cách sử dụng cơ sở dữ liệu quan hệ và SQL. Nó là hấp dẫn để
thực hiện chỉ SQL, thay vì thêm một thi logic Phần còn lại của bài báo này
được tổ chức như vậy. Trong phần 2, chúng tôi cung cấp một giới thiệu cơ bản
để các cú pháp của bình thường bảo quản đơn giản tương đương dịch sang
SQL [1]. Hơn nữa, bản dịch của các điều khoản thể hiện trong phân tầng
Trang 3
xuất hiện trong các trường hợp trên. SPC-đại số là SPCU-đại số mà không có
sự điều hành công đoàn. Descartes sản phẩm, công đoàn và sự khác biệt lập.
Các đại số SPCU-là SPCUD-đại số mà không có sự điều hành khác nhau quy
định; SPCUD-đại số là một ngôn ngữ bao gồm năm điều hành nguyên thủy
của đại số quan hệ tức là: dự án, lựa chọn,.Kể từ khi RBAC lý thuyết bảo mật
mà chúng tôi xem xét là phân tầng, các học thuyết an ninh có một mô hình

độc đáo hoàn hảoTrong phần tiếp theo chúng tôi sẽ liên quan các cuộc thảo
luận của logic hình thức điều khoản và SQL để tập hợp con của đại số-
SPCUD [1]. Các được xác định bởi các lý thuyết an ninh. Những phép được
quy định bởi một vị cho phép (U, P, O) mà U được sử dụng để bảng. bao gồm
chèn, xóa, cập nhật và chọn (đọc). Các đối tượng được bảo hộ là các bảng cơ
bản, quan điểm và thuộc tính trong cơ sở biểu thị một người sử dụng cơ sở dữ
liệu, P biểu thị một sự cho phép và O là một đối tượng trong cơ sở dữ liệu.
Các điều khoản chúng tôi xem xét[15]. Mô hình này bao gồm các thiết lập của
tất cả các hậu quả hợp lý của lý thuyết, bao gồm các thiết lập của các truy cập
được ủy quyền ngữ nghĩa thực thi là:Với một lý thuyết bảo mật RBAC và yêu
cầu của U để thực hiện một hoạt động P về O, các phương pháp tiếp cận cho
hạn chế.
3. Đại diện RB AC 1 như một học thuyết phân tầng
kiểm soát truy cập liên quan đến việc quyết định có một thể hiện của phép (U,
P, O) được ủy quyền của. Thức, các mong muốn phác thảo của đại diện và
tham khảo người đọc [4] để biết chi tiết. đại diện Các ofRBAC1as một lý
thuyết điều khoản bình thường đã được mô tả trong [4]. Trong phần này
chúng tôi cung cấp một Nếu được phép (U, P, O) THÌ thực hiện các hành
động P về O cho U ELSE cung cấp thông báo lỗi thông tin và hủy bỏ Các yêu
cầu tối thiểu của bất kỳ mô hình RBAC là nó cung cấp phương tiện để xác
định rằng điều khoản cho một hoạt động P vào một đối tượng cơ sở dữ liệu O.
ri là trực tiếp cấp cao của các rolerj trong một hệ thống phân cấp vai trò.
cao cấp "); ds là một mối quan hệ irreflexive, nội và đối xứng không. Các ví
dụ ds (ri, RJ) ghi rằng vai trò ('' Là một "không quan tâm" / vô danh biến):
senio-to (R1, R1) ds (R1,)
senio-to (R1, R1) ds (, R1)
phân công; trường hợp của RPA trong lý thuyết 1 anRBAC được sử dụng để
xác định rằng R vai trò được phân công sự cho phép để thực hiện
Các cấp cao đến vị được sử dụng trong định nghĩa của phép sau đây:
cho phép (U, P, O) ura (U, R1), cao cấp-to (R1, R2), RPA (R2, P, O)

Các thiết lập sau đây của các điều khoản định nghĩa một cấp cao, để mối quan
hệ như việc đóng cửa phản-transitive của mối quan hệ ds nơi kế thừa cho
phép P về O.hoạt động trên một đối tượng O nếu U là giao cho một vai trò R1
đó là cao cấp để một R2 vai trò trong vai trò theory'sRBAC1 hệ thống phân
cấp và R2 đã được chỉ định cho phép P về O. Đó là, U có sự cho phép P về O
nếu U là giao cho một vai trò mà Các điều khoản cho phép thể hiện rằng,
trong một thể hiện của anRBAC1 lý thuyết, một U người dùng được phép
thực hiện các P Như chúng ta sẽ thấy, cách tiếp cận chúng tôi áp dụng để đánh
giá yêu cầu truy cập dựa trên truy vấn sửa đổi [18]. Điều đó là, chúng tôi sử
dụng thông tin bảo mật để thay đổi của người sử dụng truy vấn như vậy mà
hình thức sửa đổi của truy vấn có đủ an ninh Việc chuyển nhượng của người
sử dụng và quyền cho vai trò có thể được đại diện trong logic hình thức bao
gồm các điều khoản của mặt đất trường hợp của ura (U, R) xác nhận và định
nghĩa của RPA (R, P, O) vị.cao cấp-to (R1, R2) ds (R1, R2) Định nghĩa của
phép ở trên ngụ ý rằng một chính sách truy cập đóng cửa [5] được sử dụng để
bảo vệ một cơ sở dữ liệu. Đó là,cao cấp-to (R1, R2) ds (R1, R3), cao cấp-to
(R3, R2)Một thể hiện của hệ thống phân cấp anRBAC1role có thể được đại
diện bằng cách sử dụng một tập hợp các sự kiện ds (nơi ds là viết tắt của "trực
tiếp Trong ura (U, R) có liên quan, các ura tên vị là viết tắt cho người sử dụng
vai trò phân công; trường hợp được sử dụng ura trong anRBAC1theory để đại
diện cho rằng U người dùng được phân công vai trò R. Tương tự như vậy,
RPA (R, P, O) là viết tắt cho phép-vai trò của người dùng được phép truy cập
thông tin phải được cụ thể uỷ quyền trong một lý thuyết, an ninh; người dùng
không có quyền truy cập thực hiện các hoạt động trên các đối tượng cơ sở dữ
liệu được liên kết với vai trò một, và cho người sử dụng phải được giao cho
vai trò.
Trang 4
các đặc điểm kỹ thuật của các điều khoản. chính sách truy cập có thể được thể
hiện trong cách tiếp cận của chúng tôi bằng cách làm thay đổi đơn giản để
định nghĩa về phép và thông tin trong trường hợp không từ chối mà cấm như

vậy truy cập (một chính sách mở [5]). Tuy nhiên, bất kỳ số lượng
viết tắt của "vai trò bị từ chối cho phép chuyển nhượng" andRBAC1is AC 1
với chối bỏ quyền truy cập hiện? qua RPA-d một người sử dụng U có sự cho
phép P vào một đối tượng O nếu U đã không được rõ ràng từ chối sự cho
phép này. Đối với chính sách này,định nghĩa của một RPA-d (R, P, O) vị được
bao gồm trong anRB? ACRB1theory thay vì trường hợp của RPA. Ở đây,
RPA-d là vị. Các trường hợp của RPA-d được bao gồm trong anRBAC1theory
được sử dụng để xác định rằng vai trò R là bị từ chối P được phép vào O (tức
là, R không được chuyển nhượng cho phép P về O). Các chính sách truy cập
cần thiết có thể được đại diện bởi các điều khoản sau đó thay thế các định
nghĩa của phép inRBAC1: cho phép (U, P, O) không bị từ chối (U, P, O)
Để xem cách các chính sách truy cập khác nhau có thể được đại diện, cho
rằng một chính sách truy cập mở là yêu cầu như vậy mà Định nghĩa của các
từ chối quan hệ inRBAC1is phụ như sau: Định nghĩa của? từ chối xác định
rằng quyền phủ định được kế thừa xuống trong anRBAC bị từ chối (U, P, O)
ura (U, R1), đến cao cấp (R2, R1), d-RPA (R2, P, O) RBAC chính sách an
ninh là quan trọng vì nó làm cho các đại diện của một chính sách kiểm soát
truy cập, lý luận về rằng sẽ ghi đè các giả định mặc định cho phép (U, P, O)
đúng. vai trò là hệ thống phân cấp theo quy định inRBAC1). Đó là, nếu U
được phân công vai trò R1, R2 vai trò là cấp cao các chính sách và duy trì các
chính sách tương đối đơn giản. Hơn nữa, những điều khoản có thể tương
đương để R1 trong hệ thống phân cấp anRBAC1role, và R2 đã bị từ chối cho
phép P về O sau đó? R1 và do đó bị từ chối U P truy cập vào O. Một ví dụ của
phép (U, P, O) sẽ tổ chức tại anRBAC lý thuyết 1 khi và chỉ khi không có
trường hợp của bị từ chối (U, P, O) đại diện chỉ sử dụng một số lượng nhỏ các
câu lệnh SQL.vai trò của mình khi yêu cầu truy cập. Một số trong những vai
trò có thể bị ngừng hoạt động khi người dùng hoàn thành một nhiệm vụ.
Trong của chúng tôi để quản lý các tình huống mà một cá thể của một (U, P,
O) ba là cả hai được phép và bị từ chối). Ngoài việc phân công người dùng
thông qua các định nghĩa vai trò của ura, RBAC thường yêu cầu người dùng

kích hoạt một số đại diện ofRBAC1as một lý thuyết phân tầng, các phiên có
thể được mô hình bằng cách sử dụng một kích hoạt (U, R1) vị. Một mặt đất
được phép vào O.4RBAC1in SQL
Ví dụ của kích hoạt (U, R1) được nối vào theRBAC1 lý thuyết nếu người
dùng kích hoạt thành công vai trò U R1.cho phép (U, P, O) ura (U, R1), kích
hoạt (U, R1), cao cấp-to (R1, R2), RPA (R2, P, O) Mỗi tổ chức sẽ xác định hệ
thống phân cấp vai trò của mình và vai trò cho phép. Chúng tôi đại diện cho
các vị logic như là Kể từ khi được phép, cấp cao và ds được quy định sử dụng
điều khoản xác định và ura là một tập các khẳng định mặt đất, nó sau rằng nếu
các định nghĩa của điều khoản RPA trong một thể hiện của anRBAC1theory
được thể hiện trong logic mệnh xác định sau đó 1 lý thuyết sẽ được xác định.
Nó cũng được biết rằng chức năng miễn phí, các lý thuyết dạng không đệ quy
định tại khoản AnRBAC Đó là, U có sự cho phép P về O đối tượng nếu U là
giao cho một vai trò R1, U đang hoạt động trong R1, R1 kế thừa và PSQL là
đủ mạnh để đại diện cho bất kỳ biểu hiện bằng một ngôn ngữ relationally
hoàn thành [14], nó sau đó SQL Datalog lý thuyết đệ quy không [19]) có thể
được dịch ra một bộ tương đương với các báo cáo trong đại số-SPCU [1]. Kể
từ Bất kỳ số lượng xe hybrid (mở / đóng cửa) các chính sách có thể được thể
hiện theo cách tương tự, và các chính sách mở cửa và đóng cửa có thể
được quy định như cùng tồn tại trong một lý thuyết bảo mật duy nhất (với
nhiều chính sách giải quyết cuộc xung đột [11] được đại diện Nếu kích hoạt
(U, R1) các vị được bao gồm trong anRBAC1 lý thuyết sau đó cho phép có
thể được định nghĩa như sau:SQL điểm. có một sự tương ứng một-đối-một
với bảng SQL. Có một vị (và bảng) để trực tiếp cấp cao và một cho vai trò hệ
thống phân cấp RB AC Cần lưu ý rằng ngoài những điều khoản xác định cho
phép (hoặc bị từ chối) tất cả các điều khoản trong một lý thuyết RBAC
cho phép các bài tập cụ thể cho các vai trò. Intensional truy cập xác định vị
ngầm, chúng được dịch sang được ứng dụng cụ thể. Thực tế là chỉ một số nhỏ
các khoản ứng dụng không cụ thể được yêu cầu phải thể hiện tương đương có
thể được thể hiện trong SQL bằng cách sử dụng các-SELECT FROM-

WHERE xây dựng, và điều hành của UNION là đủ mạnh mẽ để cho phép bất
kỳ công thức trong đại số-SPCU được thể hiện. Từ [1], SPC-đại số các biểu
thức
Trang 5
SQL tương ứng với các nhà điều hành công đoàn của đại số quan hệ. Đối với
đại diện các định nghĩa đệ quy của cấp cao tại
4.1RBAC1 trong SQL: biểu hiện các vấn đề
EXISTS (hoặc NOT IN) có thể được sử dụng [1].
định mệnh. Nếu an toàn [19], chức năng miễn phí và miễn phí đệ quy bình
thường logic điều khoản được sử dụng để đại diện cho ura và RPA
các khoản xuất hiện trong anRBAC1 lý thuyết sau đó lý thuyết tương đương
có thể được đại diện trong đại số-SPCUD [1]. Để SQL, các VỚI đệ quy xây
dựng là đủ từ cao cấp đến được xác định bởi một tập hợp các đệ quy tuyến
tính [3] và khẳng định, thiết lập có thể được đại diện bởi một bảng.
Trong phần này, chúng tôi thảo luận về các đại diện của anRBAC1theory
trong SQL. Từ ura là một tập hợp các nguyên tử mặt đất đại diện cho n literals
tiêu cực có thể xuất hiện trong các điều khoản trong anRBAC1 lý thuyết, các
câu lệnh SQL bao gồm không Đại diện, trong SQL, một hình thức điều khoản
định nghĩa của RPA với một tập không rỗng của các chữ trong cơ thể của
mình để bảo vệ một mối quan hệ, một định nghĩa CREATE VIEW được sử
dụng để xác định các tập hợp con của r là thành viên của một vai trò nhất định
được phép truy cập. Một câu lệnh CREATE TABLE RPA được sử dụng để ghi
lại các thiết lập của người sử dụng điều khoản có trong quan điểm và cơ sở
các bảng trong cơ sở dữ liệu. Trong trường hợp quan hệ ura nhị phân, chúng
ta sẽ giả định rằng các tên thuộc tính được sử dụng trong Một roleRBpublic
đặc biệt có thể được sử dụng để xác định quyền truy cập công cộng trên các
đối tượng. Cho rằng, chúng ta có thể bao gồm một ds (ri, công cộng)các tên
thuộc tính được R, P và O đó R là cho vai diễn, P là viết tắt của sự cho phép
và đứng O cho một đối tượng. Một TẠO Bảng báo cáo cũng được yêu cầu để
tạo ra một bảng cơ sở 2-thuộc tính tương ứng với các mối quan hệ ds.khẳng

định trong anAC1 lý thuyết cho mỗi roleri 2 Vai trò (X) (có vai trò (X) là tập
hợp các vai diễn xuất hiện trong anRBAC1
Như chúng tôi đã nói, các quan chức cao để quan hệ được định nghĩa trong
điều khoản của VỚI đệ quy và xác định các phản xạ,
transitive đóng cửa mối quan hệ ds irreflexive và nội. Trong các cuộc thảo
luận tiếp theo chúng ta sẽ cho rằng cao cấp đến cần thiết để đại diện cho phép
là:SELECT ura: U; RPA: P; RPA: O
Cuối cùng, để đại diện cho các điều khoản cho phép trong lý thuyết 1
anRBAC mô tả trước đây, một định nghĩa xem SQL được sử dụng
CREATE VIEW cho phép (U, P, O) AS để xác định các thiết lập của (U, P, O)
gấp ba như vậy mà người sử dụng U có sự cho phép P về O. Ví dụ,
forRBAC1 SQL bao gồm các cặp thuộc tính (cấp cao, cơ sở). Mỗi tuple (ri,
RJ) ở cấp cao để ghi lại rằng roleri là cao cấp để rolerj tại Điều kiện trong
việc xây dựng điều khoản thông thường có liên quan đến toán tử so sánh tiêu
chuẩn (ví dụ,>) có thể được biểu điều kiện lựa chọn trên P vị trong đặc tả hình
thức điều khoản có c không đổi là một trong những đối số của nó.Trong cái
nhìn tổng quan, bản dịch của các điều khoản liên quan đến việc bình thường
vào SQL bao gồm cả một điều kiện tham gia PX = QX trong SQL xem định
nghĩa cho mỗi cặp của các vị P và Q trong đặc tả hình thức điều khoản đó có
một biến phổ biến trong Y sử dụng các toán tử giống nhau trong SQL, và một
điều kiện tồn tại không được sử dụng trong SQL để tương đương đại diện cho
mỗi tiêu cực nghĩa đen xuất hiện trong cơ thể của một khoản. Như chúng ta sẽ
thấy, trong các đại diện của một đặc tả SQL khoản bình thường,điều kiện mô
phỏng qua các giá trị thay thế cho các biến từ một trong những điều khoản
khác cũng có thể được yêu cầu.Để thực hiện phương pháp tiếp cận của chúng
tôi, cho phép có thể được lưu giữ như là một cái nhìn hiện thực [1] mà là tính
lại (trong một trong DBMSs hiện tại không cung cấp bảo trì hiệu quả gia tăng
của các đệ quy được xác định quan điểm hiện thực - hơn nữa cremental cách)
bất cứ khi nào thay đổi được thực hiện cho các quan hệ trong điều khoản
trong đó cho phép được xác định. (Thật không may, của các xác nhận ds được

sửa đổi.tuyên bố là cần thiết để ghi lại các o đặt lý thuyết) sao cho: 9rj [ri RJ]
nắm giữ trong hệ thống phân cấp anRBAC1 vai trò (whererj 2 Vai trò (X)).
Vai trò nào là Đại diện cho SQL cho phép trong khi kích hoạt xác nhận được
bao gồm trong anRBAC1theory, một CREATE TABLE TỪ ura, RPA, cao cấp
được phép vào O được phân công công cộng.độc đáo nhất là phần tử theo thứ
tự từng phần của vai trò đó bao gồm hệ thống cấp bậc anRBAC vai trò 1 (tức
là, 8rk2Role (X) cấp cao các cá thể của hệ thống phân cấp theRBAC1 vai trò
là đại diện. CREATE TABLE tuyên bố là U và R, cho người sử dụng và vai
trò tương ứng. Đối với các RPA quan hệ tam phân, chúng tôi giả định có thể
được mô phỏng trong SQL bằng cách sử dụng một điều kiện PX = 'c' trong đó
X là tên thuộc tính trong các đại diện của SQL điều khoản mẫu đại diện).
Hiệu quả của một hằng số c xuất hiện trong một Phan vị trong đặc tả hình
thức khoản mối quan hệ để tránh recomputation của nó mỗi khi một yêu cầu
truy cập được đánh giá; cấp cao để được tính lại mỗi lần cài đặt
WHERE ura: R = cao cấp: cấp cao và cao cấp: cơ sở = RPA: R;
để (RK, công)). trường hợp thích hợp của RPA (công cộng, P, O) được thêm
vào các đặc điểm kỹ thuật bảo mật để ghi lại rằng Phong nghiên cứu là cần
thiết về kỹ thuật tốt nhất để sử dụng với các sản phẩm hiện hành) Tương tự
như vậy., cao cấp, để được lưu giữ như là một hiện thực
P và Q vị (X là tên thuộc tính phổ biến ở P và Q tương ứng với các biến Y phổ
biến ở
Trang 6
sửa đổi cần thiết để định nghĩa xem các cho phép trong SQL là cho những
việc sau tiếp tục điều kiện để được bổ sung
TỪ t1
các mệnh đề WHERE: VÀ ura.U = activate.U VÀ ura.R = activate.R;
SELECT thuế thông tin. Các truy vấn con EXISTS định cụ thể điều kiện an
ninh bổ sung phải được thỏa mãn. Ví dụ,
WHERE EXISTS (SELECT TỪ phép
Để đảm bảo truy cập duy nhất được phép là được phép, truy vấn con EXISTS

được thêm vào các yêu cầu một người sử dụng U làm cho ac-
mà đọc cho phép là cần thiết) sau đó các hình thức đọc bảo vệ các yêu cầu của
u trong SQL là:
WHERE permitted.U = 'u' và permitted.P = "đọc" và permitted.O = 't1');được
thực hiện trên t1. nếu u là nhận diện cho một người sử dụng chứng thực người
các vấn đề một câu lệnh SQL để lấy tất cả các thông tin trong một bảng t1
(đối với IF (nối vị an ninh) THEN (người sử dụng truy vấn) ELSE (thông báo
lỗi)
4.2RBAC1in SQL: Các đánh giá của các yêu cầu truy cập
Các phương pháp tiếp cận trên có sang trọng của hiện tại hoàn toàn bên trong
đại diện các ofRBAC1as một lý thuyết phân tầng.Các IF-THEN mẫu có hai
lợi thế thực dụng. Đầu tiên, nó cho phép người dùng phân biệt giữa từ chối và
trống rỗng Các EXISTS thêm điều kiện là được nối vào yêu cầu thu hồi u
phải được hài lòng để cho yêu cầu của u để một câu lệnh SELECT có thông
tin bảo mật liên kết với nó. t1 giá trị trong điều kiện permitted.O được lấy từ
các mệnh đề FROM trong câu lệnh SQL SELECT rằng vấn đề u.
Apermitted.O = ti (permitted.O = vi) là điều kiện cần thiết cho mỗi ti bảng
(xem vi) xuất hiện trong mệnh đề FROM của mỗi nhà cung cấp cung cấp cho
từng dự án). phím chính được nhấn mạnh andPno, S noandJ không được khóa
ngoài trong TỪ SPJQ, S, P, J, cho phép SELECT Jno tại London, được đặt ra
bởi các Sue người dùng xác thực trên một cơ sở dữ liệu, bao gồm các quan hệ
và các mối quan hệ Xem xét các mối quan hệ sau đây từ [6]: S (SNO, Sname,
Tình trạng, thành phố) Jfor nhà cung cấp, P (Pno, Pname, màu, cân nặng,
EXISTS (SELECT TỪ phép Thành phố) cho bộ phận, J (Jno, Jname, thành
phố) cho các dự án, và SPJQ (Pno; SNO, không có, Số lượng) (ghi số lượng
của các bộ phận P. màu "đỏ" và SPJQ.SNo = S. SNO và S. City = 'London' và
EXISTS (SELECT TỪ phép
SPJQ. Bây giờ, giả sử một truy vấn, danh sách tất cả các số dự án cho các dự
án cung cấp với các phần màu đỏ bởi các nhà cung cấp nằm
WHERE permitted.U = 'Sue và permitted.P = "đọc" và permitted.O =' S ') VÀ

EXISTS (SELECT TỪ phép
WHERE permitted.U = 'Sue và permitted.P = "đọc" và permitted.O =' P ') và
WHERE permitted.U = 'Sue và permitted.P = "đọc" và permitted.O =' J ');
EXISTS (SELECT TỪ phép
Ví dụ (Retrievals liên quan đến nhiều bảng)S, P, J và SPJQ được đọc bảo vệ.
Các hình thức đọc được bảo vệ của truy vấn SQL yêu cầu trên là:
kết quả; thứ hai, nó sẽ có hiệu quả ngay cả với các bộ vi xử lý truy vấn
DBMS mà không xử lý các vị lồng nhau một cách hiệu quả.
Đó là, bằng cách sử dụng các điều kiện an ninh phụ thêm, chúng tôi sẽ tạo ra:
Các 'u' giá trị trong permitted.u được lấy từ chi tiết đăng nhập của người dùng
u được cung cấp như một phần của chứng thực
WHERE permitted.U = 'Sue và permitted.P = "đọc" và permitted.O =' SPJQ ')
VÀ
Bằng cách đi xa hơn những gì được biểu diễn như là một khoản logic duy
nhất, chúng ta có thể thực hiện các ngữ nghĩa mong muốn, mục 2.
Đó là, một giá trị JNo có thể được tiết lộ cho Sue khi và chỉ khi nó là sự thật
trong đó một dự án với các JNo được cung cấp với các phần màu đỏ
WHERE = J. JNo = SPJ.JNo VÀ SPJQ.PNo = P. PNo VÀ
quy trình; các giá trị đọc trong permitted.P = 'đọc' xuất phát từ thực tế là một
yêu cầu để SELECT được thực hiện bởi u; và
một DBMS. Ngoài ra, một DBMS sẽ được mở rộng để xử lý các sửa đổi này
chính nó.
Với cách tiếp cận nào, chúng tôi dự tính một công cụ quản lý bảo mật được sử
dụng để sửa đổi các yêu cầu trước khi trình
Trang 7
đơn giản tiếp tục vị.
Ví dụ (Update Protection)
UPDATE P
truy cập để cho cô ấy biết rằng giá trị JNo là đúng sự thật trong 0,2
Để bảo vệ cơ sở dữ liệu từ các sửa đổi trái phép các cách tiếp cận tương tự

như mô tả ở trên được sử dụng.
WHERE màu = "đỏ" và
SET màu = 'vàng'
EXISTS (SELECT TỪ phép
Giả sử rằng Sue muốn thay đổi màu sắc của tất cả các phần màu đỏ sang màu
vàng. Cho rằng, những thay đổi yêu cầu an toàn của SQL là:
WHERE permitted.O = 'P' và permitted.P = 'update' và permitted.U = 'Sue'), 2
bởi một nhà cung cấp đặt tại London, và Sue được phép đọc các SPJQ, S, J và
P quan hệ mà bắt buộc phải đượcCần lưu ý rằng các thông tin bảo mật được
thể hiện như một truy vấn tiếp tục tích cực, có thể dịch một Như trong trường
hợp của retrievals, các IF-THEN dạng có điều kiện có thể được sử dụng cho
đại diện các yêu cầu thay đổi.và quan điểm. Tuy nhiên, nó cũng có thể để bảo
vệ các cá nhân thuộc tính xuất hiện trong một bảng. Ví dụ, một tuple
cách tiếp cận chúng tôi đã mô tả.
5 Ngoài RB AC 1
Trong các ví dụ về kiểm soát truy cập mà chúng tôi đã đưa ra ở trên, các đối
tượng đã được gọi là bảng cơ sở
được thể hiện bằng cách sử dụng định nghĩa ura, và cho phép từ chối được thể
hiện thông qua các định nghĩa d-RPA. Đây có thể chối bỏ Các thông tin bảo
mật trên các thuộc tính có thể được sử dụng để viết lại yêu cầu truy cập của
người dùng một cách an toàn bằng cách sử dụng Các khoản truy cập xác định
rằng U có sự cho phép P về O nếu U có một sự cho phép tích cực cho phép U
được sử dụng để ghi đè lên các điều khoản tích cực (nghĩa là một chối bỏ
chính sách ưu tiên có giải quyết xung đột có hiệu lực [11]).
TheRBAC1model rằng chúng ta đã nói vậy, đến nay là một đơn giản và có thể
được biểu diễn trong một số tồn tại
Để xem cách một chính sách kiểm soát truy cập lai có thể được đại diện, xem
xét một chính sách cho phép tích cực cho phép để
CHỌN TỪ phép
Các dịch truy cập vào SQL tạo ra định nghĩa xem sau (nơi được phép và bị từ

chối được xemcho phép trên O và nếu điều này cho phép tích cực không phải
là thay đổi bởi một sự phủ nhận của sự cho phép P về O để U.
CREATE VIEW truy cập (U, P, O) AS
Các hình thức có điều kiện được sử dụng trong trường hợp này sẽ là:
Kiểm soát truy cập lai một chính sách và một ủy quyền RBAC mô hình thời
có thể được đại diện.
(R1, đọc, ta) có thể được bao gồm trong RPA để ghi lại rằng vai trò r1 được
gán sự cho phép đọc trên thuộc tính của một trong bảng
RDBMSs. Tuy nhiên, một điểm thu hút của cách tiếp cận của chúng tôi là nó
có thể được kéo dài trong nhiều cách để thực hiện
những người bao gồm trong SQL. Kể từ khi yêu cầu an ninh có thể sẽ là mạnh
ứng dụng và tổ chức cụ thể,
an ninh chính sách, có thể không được đại diện trong RDBMSs hiện có, và
không yêu cầu bất kỳ tính năng ngôn ngữ ngoài
tính linh hoạt của chúng tôi là cung cấp phương pháp tiếp cận là rất quan
trọng trong thực tế. Để chứng minh sức mạnh của phương pháp tiếp cận của
chúng tôi, chúng tôi hiển thị như thế nào
Đại diện cho 5,1 Hybrid Chính sách truy cập trong SQL
truy cập (U, P, O) cho phép (U, P, O), không bị từ chối (U, P, O)
Các tiên đề cốt lõi xác định các thiết lập của các truy cập được ủy quyền có
thể được đại diện trong logic hình thức điều khoản như vậy (nơi được phép
và từ chối như quy định tại mục 3):
được định nghĩa trong SQL sử dụng phương pháp xác định trước):
WHERE không EXISTS (SELECT từ chối);
Trang 8
NẾU KHÔNG THÌ bị từ chối (người sử dụng truy vấn) ELSE (thông báo
lỗi)kèm điều kiện.Đại diện ủy quyền tạm thời 5,2 Mô hình trong SQL
được đánh giá trước khi cho phép có thể được sử dụng. Trong trường hợp này,
SQL sẽ bao gồm các vị giới hạn trong
Một khái quát tự nhiên sẽ được cho phép chuyển nhượng quyền hạn chế.

Thay vì chỉ đơn giản gáncho phép một vai trò (một cặp, dễ dàng thể hiện bằng
một bảng), người ta cũng có thể đính kèm một giới hạn vị [16] cầncác đối
tượng cơ sở dữ liệu được thể hiện trong logic hình thức phân tầng khoản của
điều khoản sau đây:cho phép (truy cập (U, P, O), T) xảy ra (E1, T1), khởi (E1,
ura (U, R1)), T1 <T,thời RBAC (TRBAC) mô hình từ [4]. Các tiên đề cốt lõi
của mô hình này xác định các thiết lập của điều khoản người dùng trên
cao cấp-to (R1, R2),
Để minh họa cho phép các mô hình thời có thể được thể hiện trong SQL,
chúng ta xem xét các đại diện của chưa kết thúc (RPA (R2, P, O), T, T2),
không dừng lại (E2, RPA (R2, P, O), T)xảy ra (E2, T2), khởi (E2, RPA (R2, P,
O)), T2 <T,Và khởi ura.R = seniorto.senior và khởi rpa.R = seniorto.juniorVÀ
H1.T <CURRENTTIMEVÀ KHÔNG EXISTS (SELECT TỪ ngừng ura)
P truy cập vào O, một (T truy cập (U, P, O),) cho phép truy vấn được thực
hiện bởi hệ thống an ninh. Người dùng U sẽ được ủy quyền
VÀ KHÔNG EXISTS (SELECT TỪ ngừng RPA);
ngày hết hạn của thời gian mà R2 vai trò là ủy quyền thực hiện hành động P
về OViệc đọc sách của khoản này là như sau: vào thời gian T (lấy từ "đồng hồ
hệ thống") mà một người sử dụng U yêu cầu
được giao cho một vai trò R1, R1 đã thừa hưởng từ một số vai trò, R2, được
sự cho phép để thực hiện các hoạt động P về Ođể thực hiện các hành động P
yêu cầu nếu một sự kiện bảo mật [4] đã xảy ra mà bắt đầu một khoảng thời
gian trong đó UVÀ KHÔNG EXISTS (SELECT TỪ kết thúc RPA)
Đại diện cho các tiên đề cho phép trong SQL, các mã sau đây có thể được sử
dụng:
6 hạn chế, RBAC 3 và SQL
mà tại đó người sử dụng làm một yêu cầu truy cập. Các ura khởi, khởi RPA,
ura kết thúc, dừng lại ura, RPA đã kết thúc vàCURRENTTIME là một hàm trả
về "thời gian hiện tại", được lấy từ đồng hồ hệ thống của DBMS, thời gian
Hạn chế được một phần quan trọng của RBAC [17]. WhilstRBAC2models
bao gồm hạn chế, chúng tôi sẽ xem xét thêm cách mà cho phép được. Hơn

nữa, xảy ra có thể được thể hiện trong SQL bằng cách tạo ra một bảng cơ sở 2
thuộc tính.cho đại diện các ràng buộc về anRBAC3theory. Bản chất cao cấp
của logic điều này làm cho nó dễ dàng cho một SA logic vào SQL có thể được
dễ dàng và hiệu quả tự động. quan hệ RPA dừng lại được thể hiện dưới hình
thức phân tầng logic điều khoản trong [4], và có thể được dịch sang SQL
trong cùng hoặc DBA để xây dựng hạn chế về lý thuyết an ninh. Một giao
diện đồ họa cũng có thể được sử dụng bởi các SA hay DBA để giúp họ
CREATE VIEW cho phép (U, P, O) AS
chưa kết thúc (ura (U, R1), T, T1), không dừng lại (E1, ura (U, R1), T),
đã được giao cho R2, sự phân công của U để R1 đã được kết thúc bằng một
sự kiện không hay an ninh hết hạn khởi SELECT ura.U, rpa.P khởi, khởi
rpa.O
TỪ xảy ra H1, H2 xảy ra, khởi ura, RPA khởi, cao cấp-to
phù hợp với phương pháp tiếp cận các mô tả ở trên, cách tiếp cận của chúng
tôi liên quan đến việc sử dụng logic hình thức điều khoản như một ngôn ngữ
đặc tảVÀ KHÔNG EXISTS (SELECT TỪ kết thúc ura)
WHERE H1.E = khởi ura.E VÀ H2.E = khởi rpa.E
giao U để R1, và được sự cho phép P trên O cho R2 đã không được kết thúc
bằng một sự kiện bảo mật cũng không phải
xây dựng chế. Hơn nữa, có thể dịch các chi tiết kỹ thuật hình thức ràng buộc
điều khoản của một thành SQL tương đương với hình thức đó là rất hiệu quả
để kiểm tra, quá trình dịch hạn chế thể hiện dưới dạng khoản Tổng hợp
ofRBAC. thứ hai cho phép các lý thuyết bảo mật RBAC để bao gồm cả hạn
chế và phân cấp vai trò. Trong
Trang 9
giá trị đúng (thoả mãn) trong aRBAC3 lý thuyết.
Trong cách tiếp cận của chúng tôi, khó khăn ban đầu được viết bằng mẫu tức
là từ chối: L1, L2 , , Ln (nơi Li (i = (1 n)) là một chữ
hạn chế về lý thuyết RBAC.
Từ chối có thể được thể hiện bằng cách sử dụng hằng hoặc biến, có thể cho

một SA để làm cho các khó khăn trên
đại diện của lý thuyết an ninh, và cho phép chúng tôi khai thác Nicolas "Đơn
giản hoá phương pháp [13] khi kiểm traRBAC3 lý thuyết là cụ thể hoặc là nói
chung như là bắt buộc. Tuy nhiên, chúng tôi tin rằng những hạn chế cần phải
được viết trong lúckhẳng định trong lý thuyết 3 aRBAC. Như chúng ta sẽ
nhìn thấy, những bộ khẳng định được đại diện bằng cách sử dụng các bảng cơ
sở trong SQLandn> 0). Việc đọc báo cáo này là nó không thể cho các kết hợp
của các chữ L1 L2 ^ ^ ^ Ln đến đưa vào tiêu chuẩn SQL3 và đã được hỗ trợ
trong RDBMSs thương mại. Tất nhiên, khẳng định nhà nước ments có thể
được sử dụng để đại diện cho những hạn chế về RBAC đại diện trong SQL.
Tuy nhiên, trong khi hạn chế thể hiện trongura (U, R1), ura (U, R2), ssd (R1,
R2)Đại diện cho những hạn chế về lý thuyết bảo mật RBAC chúng tôi chọn
để sử dụng gây ra; gây được đề nghị bày tỏ rằng người dùng không thể được
ghi lại trong anRBAC3theory như đang được giao cho một đôi vai trò đó là
tĩnh Hình thức chung một lúc là có thể, và phải được chuyên môn tại thời
điểm kiểm tra các trường hợp sử dụng các ứng dụng cụ thể để thử nghiệm cho
thỏa mãn ràng buộc. Để thấy rằng xem xét một tách tĩnh của ràng buộc nghĩa
vụ [17] được sử dụng để hạn chế này quy định rằng: đó là không thể cho
người sử dụng được ghi lại trong anRBAC3theory như đang được giao cho
một cặp (R1, R2) các vai trò đó được quy định như được tĩnh tách biệt nhau.
Các ura (U, R1) và ura (U, R2) điều kiện được sử dụng để thể hiện sự hạn chế
ssd ở dạng tổng quát nhất của nó và một bộ khẳng định ssd được sử dụng để
ghi lại đôi vai trò cụ thể của Bảng ssd là dân cư với các bộ dữ liệu bao gồm
một cặp giá trị (ri, RJ) (whereri, RJ 2 Vai trò (X)) và, vì thể hiện bởi các
sentence8 phổ đóng cửa: câu (^ L1 L2 Ln) các existentially đóng cửa và do
đó: 9 (L1 Hình thức từ chối các ràng buộc ssd có thể dễ dàng dịch sang một
tuyên bố khẳng định CREATE trong SQL.TẠO KIỂM TRA khẳng định ssd
L2 Ln). Do đó, để thể hiện các biểu mẫu điều khoản của chế ssd trong SQL
các câu sau đây T) tuyên bố có thể được sử dụng (whereTi andTj là các loại
liên quan đến vai trò các thuộc tính và loại trừ (ví dụ, vai trò)).đối xứng của

các mối quan hệ ssd, bổ sung sẽ bao gồm các cặp vai trò (RJ, ri) (i6 = k).
TỪ ura U1, ura U2, ssd
WHERE U1.S = U2.S VÀ U1.R = ssd.role VÀ U2.R = ssd.excluded);
có thể được sử dụng và được kiểm tra mỗi lần một tuple được đưa vào ura:
đại diện một cách tự nhiên bằng cách sử dụng kích hoạt trong SQL. Trong bối
cảnh ofRBAC lý thuyết an ninh 3, tương đương có thể được giải thích
là có nghĩa là nếu một sự thay đổi lý thuyết 3 anRBAC thể hiện trong logic
hình thức phân tầng không vi phạm điều khoản ràng buộc
SQL có thể được dễ dàng và hiệu quả tự động. Hơn nữa, nó là một vấn đề
thường xuyên để thực thi từng bước khẳng định bởi
câu. Hạn chế thể hiện dưới dạng phạm vi có sức hấp dẫn của dịch để một hình
thức tương đương có thể sẽ được
Phương pháp chúng tôi áp dụng cho các đại diện hạn chế onRBAC3theories
được dựa trên các công việc trong [9] và liên quan đến
không bị từ chối bởi các đại diện của tôi như là một kích hoạt trong SQL. Quá
trình dịch hạn chế ở dạng nhiều thànhlý thuyết. Việc kích hoạt mà đại diện
cho những hạn chế về anRBAC3 lý thuyết đại diện trong SQL có thể được
biểu hiện dướichúng tôi sẽ sử dụng ri ký hiệu để chỉ các đối số thứ i của tuple
để được chèn / xóa từ một r liên quan tùy ý).gây ra có logic khai thác thực tế
là trước khi cập nhật hiện tại hạn chế đã được thỏa mãn.Mối quan hệ (xóa)
chèn được sử dụng để lưu trữ các bộ dữ liệu được đưa vào (xóa) trong một
giao dịch thay đổi về anRBAC3 Đối với các ràng buộc ssd thể hiện trong hình
thức từ chối abovNOT EXISTS tách biệt nhau. Trong hình thức từ chối hạn
chế có thể được thể hiện như sau:
(SELECT chủ đề, ssd.role, ssd.excluded
được tĩnh tách biệt nhau. Đại diện cho bộ khẳng định ssd trong SQL, một
CREATE TABLE ssd (roleTi, loại trừ từ chối biểu mẫu có một đại diện rất
đơn giản như là xác nhận, các đại diện đang không ở trong một hình thức tối
ưu hạn chế thể hiện ở nhiều hình thức [8]. báo cáo là dưới hình thức nhiều
nếu nólà một existentially định lượng đặt hàng đầu tiên vi phạm ràng buộc bởi

quy định cụ thể rằng một hành động ROLLBACK là để được thực hiện nếu
tính toàn vẹn bị vi phạm. Như là bình thường trong cơ sở dữ liệu SQL, hai bộ
nhớ đệm và các mối quan hệ người dùng không truy cập được chèn vào và
xóa được giả định tồn tại Tôi thể hiện dưới dạng từ chối (và tương đương ở
dạng dải), sau đó thay đổi lý thuyết RBAC thể hiện trong SQL với n thuộc
tính tương ứng với trình độ của bảng vào đó một tuple là để được thêm vào
hoặc xóa (trong phần tiếp theo Kể từ khi từ chối trong logic hình thức phủ
định và điều khoản hiện đang phổ biến định lượng, L1, L2 , , Ln có thể
được
Trang 10
CREATE TRIGGER về ura CHO INSERT
IF (EXISTS (SELECT FROM WHERE chèn
EXISTS (SELECT TỪ ura U1, ssd WHERE u1.user = inserted.1 VÀ
inserted.2 = ssd.role)
ROLLBACK Và EXISTS (SELECT TỪ ura u2, ssd WHERE ssd.excluded =
u2.role)))
các hạn chế ssd trên anRBAC3 lý thuyết sẽ bị vi phạm. chèn vào lý thuyết 3
anRBAC, ui cũng được ghi lại như đang được giao cho một rolerk trong ura,
và (RJ, RK) là một tuple trong
7 Kết luận và làm việc thêm
Ý nghĩa của câu lệnh SQL như sau: nếu (ui, RJ) là cặp giá trị trong các tuple
ura đó là đề nghị Bất kỳ số lượng các loại (tĩnh) hạn chế về anRBAC3 lý
thuyết (ví dụ, điều kiện tiên quyết cho phép và cardinality hạn chế về vai trò)
có thể được thể hiện trong cách cơ bản giống như ssd là.Các chương trình,
Proc. ACM quả, năm 1986.[2] Căn hộ, K., và Bezem, M., Ayclic chương
trình, máy tính thế hệ mới, năm 1990.xây dựng cao cấp trong đó có ngữ nghĩa
rõ ràng. Chúng tôi đã chỉ ra làm thế nào có thể được thực hiện. Phương pháp
mà chúng tôiCác thách thức lớn cho việc cải thiện việc xây dựng các chính
sách kiểm soát truy cập là cung cấp các học viên với sử dụng,ssd bảng có ghi
đôi vai trò là loại trừ lẫn nhau sau đó yêu cầu chèn là cuộn lại vì nếu không[3]

Bancilhon, F., Maier, D., Sagiv, Y., và Ullman, J., Magic Sets và cách kỳ lạ
khác để Thực hiện Logic1861 LNAI, Springer, 2000.[4] Barker, S., Bảo vệ dữ
liệu bằng cách lập trình Logic, 1 Conf quốc tế. về Logic Máy Tính
(CL2000),Hệ thống, Benjamin Cummings, năm 1987.[7] Ngày, C., và
Darwen, A., A Hướng dẫn về tiêu chuẩn SQL, Addison Wesley.[9] Decker, H.,
SoundCheck cho SQL, PADL01, năm 2001.[6] Ngày, C., An Giới thiệu về hệ
thống cơ sở dữ liệu, bản thứ 7, Addison Wesley, 2000.tập hợp con của SQL3.
[10] Ferraiolo, D., Gilbert, D., và Lynch, N., Một xem xét về chính sách
thương mại liên bang và Access Control đã mô tả cho phép một DBA hay SA
để xác định một loạt các chính sách kiểm soát truy cập bằng cách sử dụng các
yếu tố của RBAC rằng bản đồ Tài liệu tham khảo trực tiếp vào logic phân
tầng. Hơn nữa, chúng tôi đã chứng minh làm thế nào các cấu trúc có thể được
thực hiện bằng cách sử dụng một nhỏ Sự phát triển của các công cụ cho các
dịch tự động của chính sách RBAC chi tiết kỹ thuật thể hiện trong logic phân
tầng vào SQL là một vấn đề cho công việc hơn nữa. Chúng tôi cũng dự định
điều tra cách thức mà các thủ tục giấy tờ chứng minh được sử dụng trong [5]
Castano, S., Fugini, M., Martella, G., và Samarati, P., cơ sở dữ liệu bảo mật,
Addison Wesley, 1995.logic phân tầng có thể được khai thác để giúp các quản
trị viên để rút ra kết luận và hiểu được hành vi của các truy cập Nhu cầu,
Proc. NIST-NCSC An ninh Quốc gia Conf., Năm 1993. [1] Abiteboul, S.,
Hull, R., và Vianu, V., nền tảng của Cơ sở dữ liệu, Addison Wesley, 1995.
[11] Jajodia, S., Samarati, P., và Subrahmanian, V., một ngôn ngữ hợp lý cho
Authorizations Bày tỏ, Proc. IEEE Symp. An ninh và bảo mật, năm 1997.
[8] Decker, H., Integrity Hạn chế thực thi trên cơ sở dữ liệu Suy trong
Kerschberg, L (Ed.) chuyên gia cơ sở dữ liệu
[12] Lloyd, J., nền tảng của lập trình Logic, 2nd Ed, Springer., Năm 1987.
chính sách kiểm soát họ chỉ định.
Trang 11
Springer, 1989.
[13] Nicolas, J., Logic để tăng cường kiểm tra toàn vẹn trong cơ sở dữ liệu

quan hệ, Informatica Acta, 18, năm 1982.Năm 1996.[15] Przymusinski, T.,
ngữ nghĩa mô hình hoàn hảo, Proc. ICLP 5 năm 1988.Proc. 14 IFIP Conf. trên
cơ sở dữ liệu an, năm 2000.Hội thảo về Quản lý dữ liệu, năm 1975.[18]
Stonebraker, M., thực hiện chế Integrity và xem bằng cách sửa đổi truy vấn,
Proc. SIGMOD[17] vey, R., Coyne, E., Feinstein, H., và Youman, C., Role-
Based Access Control Mô hình, IEEE Computer,[14] Paradaens, J., de Bra, P.,
Gyssens, M., và Gucht van, D., Cấu trúc của mô hình cơ sở dữ liệu quan hệ,
[16] Rosenthal, A., và Sciore, E., mở rộng của SQL Grant và Thu hồi hoạt
động để hạn chế và Kích quyền ưu đãi,[19] Ullman, J., nguyên tắc của cơ sở
dữ liệu và hệ thống cơ sở tri thức: Tập 1, Khoa học Máy tính Press, 1990.