Tìm hiểu về Row Level Security (RLS)

BAN CƠ YẾU CHÍNH PHỦ
HỌC VIỆN KỸ THUẬT MẬT MÃ

BÁO CÁO BÀI TẬP LỚN

TÌM HIỂU VỀ CƠ CHẾ AN TOÀN MỨC HÀNG
(ROW-LEVEL SECURITY)
VÀ TẤN CÔNG KÊNH KỀ VƯỢT QUA CƠ CHẾ
NÀY TRONG SQL SERVER

Học phần

: An toàn cơ sở dữ liệu

Giảng viên hướng dẫn : Trần Thị Lượng
Sinh viên thực hiện

: Nguyễn Thị Kim Huế AT13CLC0110

Hà Nội, 2019



Nhận xét của giảng viên:
………………………………………………………………………………………
………………………………………………………………………………………
………………………………………………………………………………………
………………………………………………………………………………………
………………………………………………………………………………………
………………………………………………………………………………………
………………………………………………………………………………………

………………………………………………………………………………………
………………………………………………………………………………………
………………………………………………………………………………………
………………………………………………………………………………………
………………………………………………………………………………………
………………………………………………………………………………………
………………………………………………………………………………………
………………………………………………………………………………………
………………………………………………………………………………………
………………………………………………………………………………………
………………………………………………………………………………………
………………………………………………………………………………………
………………………………………………………………………………………
………………………………………………………………………………………
………………………………………………………………………………………
………………………………………………………………………………………
………………………………………………………………………………………
………………………………………………………………………………………
………………………………………………………………………………………
………………………………………………………………………………………
………………………………………………………………………………………
Chữ ký của giảng viên


MỤC LỤC


LỜI MỞ ĐẦU
Dữ liệu của mỗi tổ chức, doanh nghiệp luôn là điều quan trọng nhất và bộ
phận công nghệ thông tin của họ phải có nhiều biện pháp để đảm bảo dữ liệu

không rơi vào tay kẻ xấu. Các lập trình viên DBA (Database Administrator) cần
thiết lập các lớp bảo mật khác nhau trên các dữ liệu để từng người dùng chỉ có thể
xem dữ liệu, hàng được lọc từ một bảng mà họ có quyền truy cập. Các lập trình
viên DB thường tạo ra các khung nhìn trừu tượng hoặc các thủ tục được lưu trữ với
logic phức tạp trên đầu bảng bằng cách sử dụng các bảng ánh xạ có chứa khóa truy
cập dữ liệu người dùng. Đôi khi các logic bảo mật này không tuân theo các tiêu
chuẩn và có thể có nhiều phiên bản khác nhau trên cơ sở dữ liệu và do đó, việc
theo dõi, cập nhật trở nên khó khăn, khó kiểm soát. Câu hỏi đặt ra là : “Có tính
năng bảo mật nào có sẵn trong SQL Server có thể đáp ứng yêu cầu này
không?”.Trong SQL Server 2016, nhiều tính năng bảo mật mới đã được giới thiệu
như Bảo mật cấp độ hàng, ‘Luôn mã hóa,’ Mặt nạ dữ liệu động, và ‘Tăng cường
mã hóa dữ liệu trong suốt sẽ giúp người dùng bảo vệ dữ liệu của họ.
Trong bài báo cáo này, tôi sẽ thảo luận về một trong những tính năng bảo
mật đó là Row Level Security (RLS), cho phép kiểm soát quyền truy cập vào các
hàng trong một bảng. Row Level Security cho phép bạn thực hiện các hạn chế đối
với dữ liệu dựa trên các đặc điểm của người dùng đang thực hiện truy vấn. RLS
giúp kiểm soát truy cập dữ liệu dễ dàng với độ trong suốt hoàn toàn cho những
người dùng khác nhau.


PHẦN 1. TỔNG QUAN VỀ CƠ CHẾ AN TOÀN MỨC HÀNG
(ROW-LEVEL SECURITY)
1.1.

Tìm hiểu về Row-level Security (RLS)

Ở SQL Server 2016 trở đi có giới thiệu một tính năng gọi là bảo mật cấp độ
hàng(Row-level security). RLS cho phép giới hạn việc truy xuất các hàng (record)
dựa trên các thuộc tính của người dùng thực thi (chẳng hạn như vai trò hoặc bộ
phận) thông qua các chính sách bảo mật security policy. Một chính sách bảo mật

mô tả các quy định quản lý việc truy xuất các dòng dữ liệu.
Dưới đây là các ví dụ thiết kế về cách sử dụng RLS:
- Một bệnh viện có thể tạo ra một chính sách bảo mật cho phép các y tá chỉ
xem các hàng dữ liệu cho bệnh nhân của họ.
- Ngân hàng có thể tạo chính sách để hạn chế quyền truy cập vào các hàng
dữ liệu tài chính dựa trên bộ phận kinh doanh hoặc vai trò của nhân viên trong
công ty.
- Một ứng dụng nhiều người thuê có thể tạo ra một chính sách để thực thi sự
phân tách hợp lý các hàng dữ liệu của mỗi người thuê với các hàng của người thuê
khác. Hiệu quả đạt được bằng cách lưu trữ dữ liệu cho nhiều người thuê trong một
bảng. Mỗi người thuê chỉ có thể thấy các hàng dữ liệu của họ.
RLS giới thiệu kiểm soát truy cập dựa trên predicate. Nó có tính năng đánh giá
linh hoạt, tập trung, dựa trên predicate. Predicate có thể dựa trên siêu dữ liệu hoặc
bất kỳ tiêu chí nào khác mà quản trị viên xác định là phù hợp. Predicate được sử
dụng làm tiêu chí để xác định xem người dùng có quyền truy cập phù hợp vào dữ
liệu dựa trên các thuộc tính người dùng hay không? Kiểm soát truy cập dựa trên
nhãn có thể được thực hiện bằng cách sử dụng kiểm soát truy cập dựa trên
predicate.


1.2.

Một số khái niệm sử dụng trong RLS

Có ba khái niệm cốt lõi được sử dụng trong RLS
a. Predicate function(hàm vị từ): Hàm có giá trị bảng nội tuyến thực hiện logic

điều khiển truy cập (ví dụ: trả về một hàng hay không tùy thuộc vào tên chính,
vai trò hoặc các thuộc tính khác của người dùng gọi).
b. Security predicate(vị từ bảo mật): Liên kết một predicatefunction vào một

bảng (ví dụ: áp dụng một hàm kiểm tra vai trò của nhân viên cho bảng Danh
sách lương ). Có hai loại security predicates:
• Filter predicates: Âm thầm lọc các hàng có sẵn để đọc các hoạt động
(SELECT, UPDATE và DELETE).
• Block predicates: chặn các hoạt động ghi (AFTER INSERT, AFTER
UPDATE, BEFORE UPDATE, BEFORE DELETE) vị phạm predicates.
c. Security policy(chính sách bảo mật): Một tập hợp các Security
predicatesđược áp dụng trong một đối tượng gọi là chính sách bảo mật. (ví dụ:
bạn có chính sách ”Tài khoản” áp dụng nhiều predicate function cho các bảng
liên quan đến “Tài khoản” và có 1 chính sách “Nhân sự” áp dụng một số
predicate function cho các bảng HR khác nhau).
Quyền truy cập vào dữ liệu cấp hàng trong bảng bị hạn chế bởi một security
predicate được xác định là hàm có giá trị bảng nội tuyến. Hàm này sau đó được gọi
và thực thi bởi security policy. Đối với các filter predicates, ứng dụng không biết
các hàng được lọc từ tập kết quả. Nếu tất cả các hàng được lọc, thì một bộ null sẽ
được trả về. Đối với block predicates, mọi thao tác vi phạm predicates sẽ không
báo lỗi.
Filter predicates được áp dụng trong khi đọc dữ liệu từ bảng cơ sở. Chúng ảnh
hưởng đến tất cả các hoạt động nhận: SELECT, DELETE and UPDATE. Người
dùng không thể chọn hoặc xóa các hàng được lọc. Người dùng không thể cập nhật
các hàng được lọc. Nhưng, có thể cập nhật các hàng theo cách mà chúng sẽ được
lọc sau đó. Block predicates ảnh hưởng đến tất cả các hoạt động ghi.
-

AFTER INSERT and AFTER UPDATE predicates : Có thể ngăn người dùng
cập nhật các hàng thành các giá trị vi phạm predicate.


-

BEFORE UPDATE predicates: Có thể ngăn người dùng cập nhật các hàng

-

hiện đang vi phạm predicate
BEFORE DELETE predicates: Có thể chặn hoạt động delete.
1.3.

Những hành vi Filter predicates

Xác định security policy lọc các hàng của bảng. Ứng dụng không biết về
bất kỳ hàng nào được lọc cho các hoạt động SELECT, UPDATE và DELETE. Bao
gồm các tình huống trong đó tất cả các hàng được lọc ra. Ứng dụng có thể INSERT
các hàng, ngay cả khi chúng sẽ được lọc trong bất kỳ hoạt động nào khác.

1.4.

Những hành vi Block predicates

Block predicates cho UPDATE: được chia thành các hoạt động riêng biệt
cho BEFORE và AFTER. Do đó, ví dụ, bạn không thể chặn người dùng cập nhật
một hàng để có giá trị cao hơn giá trị hiện tại. Nếu loại logic này là bắt buộc, bạn
phải sử dụng các kích hoạt với các bảng trung gian DELETED và INSERTED để
tham chiếu các giá trị cũ và mới cùng nhau.
Trình tối ưu hóa sẽ không kiểm tra block predicate AFTER UPDATE nếu
các cột được sử dụng bởi predicate function không thay đổi. Ví dụ: Alice không thể
thay đổi mức lương lớn hơn 100.000. Alice có thể thay đổi địa chỉ của một nhân
viên có mức lương đã lớn hơn 100.000 miễn là các cột được tham chiếu trong
predicate không thay đổi.
1.5.

Những hạn chế của cơ chế RLS

Có một vài hạn chế khi sử dụng cơ chế RLS như sau :
- Predicate functionphải được tạo bằng SCHEMABINDING. Nếu một function
được tạo mà không có SCHEMABINDING và khi ta cố gắng liên kết nó với một
chính sách bảo mật, nó sẽ đưa ra một lỗi.
- Các khung nhìn không thể được tạo trên một bảng mà RLS
- Các bảng trong bộ nhớ không được hỗ trợ cho RLS.


- Giảm hiệu suất người dùng


PHẦN 2. TRIỂN KHAI CƠ CHẾ ROW-LEVEL SECURITY
2.1. Cách tạo security policy
Tạo một chính sách bảo mật cho bảo mật cấp hàng.
Cú pháp:

Đối số :
security_policy_name :Tên của chính sách bảo mật. Tên chính sách bảo mật phải
tuân thủ các quy tắc cho mã định danh và phải là duy nhất trong cơ sở dữ liệu và
lược đồ của nó.
schema_name : Là tên của lược đồ mà chính sách bảo mật thuộc về. Lược đồ được
yêu cầu vì liên kết lược đồ.
[ FILTER | BLOCK ] : Loại vị từ bảo mật cho hàm được liên kết với bảng đích.
FILTER biến vị ngữ âm thầm lọc các hàng có sẵn để đọc các hoạt động. Các biến
vị ngữ BLOCK rõ ràng chặn các hoạt động ghi vi phạm predicate function.
tvf_schema_name.security_predicate_function_name : Là hàm giá trị bảng nội
tuyến sẽ được sử dụng làm vị ngữ và sẽ được thực thi khi truy vấn đối với bảng

mục tiêu. Nhiều nhất một biến vị ngữ bảo mật có thể được xác định cho một hoạt
động DML cụ thể đối với một bảng cụ thể. Hàm giá trị bảng nội tuyến phải được
tạo bằng tùy chọn SCHEMABINDING.
{ column_name | expression } :Tên hoặc biểu thức cột được sử dụng làm tham số
cho hàm vị ngữ bảo mật.
table_schema_name.table_name:Là bảng mục tiêu mà vị từ bảo mật sẽ được áp
dụng. Nhiều chính sách bảo mật bị vô hiệu hóa có thể nhắm mục tiêu một bảng cho
một hoạt động DML cụ thể, nhưng chỉ có thể bật một chính sách tại bất kỳ thời
điểm nào.
<block_dml_operation>:Hoạt động DML cụ thể mà vị từ khối sẽ được áp dụng.
[ STATE = { ON | OFF } ] :Cho phép hoặc vô hiệu hóa chính sách bảo mật để thực
thi các vị từ bảo mật của nó đối với các bảng mục tiêu. Nếu không được chỉ định,
chính sách bảo mật được tạo sẽ được bật.
[ SCHEMABINDING = { ON | OFF } ] : Cho biết liệu tất cả các hàm vị ngữ trong
chính sách phải được tạo bằng tùy chọn SCHEMABINDING. Theo mặc định, tất
cả các chức năng phải được tạo bằng SCHEMABINDING.
[table_schema_name.] table_name : Là bảng mục tiêu mà vị từ bảo mật sẽ được
áp dụng. Nhiều chính sách bảo mật bị vô hiệu hóa có thể nhắm mục tiêu một bảng
duy nhất, nhưng chỉ có thể bật một chính sách tại bất kỳ thời điểm nào.


2.2. Triển khai RLS với “Filter Predicate”
2.1.1. Tạo tài khoản người dùng
- Ví dụ ở đây tạo 3 tài khoản :
1. Giáo viên chủ nhiệm(user_gvcn)
2. Lớp trưởng lớp CLC(user_loptruongclc)
3. Lớp trưởng lớp CT(user_loptruongct)

- Tạo bảng sinh viênvà chèn dữ liệu:


-

2.1.2. Tạo hàm có giá trị bảng nội tuyến chứa Filter Predicate

2.1.3. Tạo Security Policy và thêm Filter Predicate



Predicate chặn theo ý của mình. Sang phần sau chúng ta sẽ tìm hểu rõ hơn về
Block Predicate.
2.3. Triển khaiRLS với “BlockPredicate”

Từ kết quả thông báo lỗi không cho thực thi, chúng ta có thể thấy BLOCK
Predicate đang chặn người dùng user_loptruongclc chèn bản ghi mà sau khi người
dùng chèn không có quyền truy cập vào nó.


2.4. Xem danh sách các Security Predicates và Security Policies
2.4.1. Xem danh sách Security Policies

2.4.2. Xem danh sách predicates security


PHẦN 3. TẤN CÔNG KÊNH KỀ VÀO CƠ CHẾ RLS
3.1. Tổng quan về tấn công kênh kề
Tấn công kênh kề (Side-Channel Attacks) là một nỗ lực truy cập dữ liệu ẩn
bởi người dùng độc hại biết cơ chế bảo mật được triển khai như thế nào. Thủ thuật

được sử dụng là buộc truy vấn đưa ra một ngoại lệ, giả dụ như lỗi tràn hoặc chia
cho số không. Kiểu tấn công này sẽ không hiển thị cho kẻ tấn công dữ liệu cơ bản,
nhưng sẽ cho phép họ suy luận dữ liệu.
Các cuộc tấn công như vậy sẽ yêu cầu thông đồng (hoặc cấp phép quá mức
được cấp cho người dùng độc hại) và có thể sẽ yêu cầu một số lần sửa đổi chính
sách (yêu cầu quyền xóa vị từ để phá vỡ liên kết lược đồ), sửa đổi các hàm có giá
trị của bảng nội tuyến và liên tục chạy các câu lệnh chọn trên bảng đích. Nên giới
hạn quyền khi cần thiết và theo dõi mọi hoạt động đáng ngờ. Hoạt động như chính
sách thay đổi liên tục và các hàm có giá trị bảng nội tuyến liên quan đến bảo mật
cấp hàng cần được giám sát.
3.2. Thực hiện tấn công kênh kề
- Thực hiện tấn công bằng cách đưa ra truy vấn ngoại lệ Divide By Zero.


TÀI LIỆU THAM KHẢO
[1] />[2] />[3] />