Khám phá chuyên sâu về bảo mật cấp hàng

Giới thiệu

Các tổ chức ngày càng trở nên quan tâm hơn về việc làm thế nào để giảm chi phí cấp phép cho các giải pháp cơ sở dữ liệu bằng cách sử dụng hợp nhất. Một số hợp nhất có thể đạt được trong SQL Server đơn giản bằng cách tận dụng mối quan hệ một-nhiều hiện có giữa các phiên bản và cơ sở dữ liệu. Tuy nhiên, có những trường hợp giải pháp yêu cầu dữ liệu được hợp nhất thành một bảng. Trong trường hợp như vậy, có thể có những lo ngại về cách hạn chế quyền truy cập vào dữ liệu.

Row Level Security đã được giới thiệu trong SQL Server 2016 như một giải pháp cho các trường hợp tương tự như trên. Nó cho phép bạn hạn chế quyền truy cập vào các hàng trong bảng dựa trên các điều kiện được xác định trong một Hàm có giá trị trong bảng được gọi là Hàm dự đoán . Khi một Chức năng Dự đoán được áp dụng cho bảng người dùng chứa dữ liệu tổng hợp, hệ thống có thể được định cấu hình để trả về các tập dữ liệu khác nhau cho những người dùng khác nhau tùy thuộc vào vai trò của họ, điều này lần lượt phụ thuộc vào mô tả công việc hoặc phòng ban của họ.

Tình huống

Chúng tôi sẽ xây dựng một kịch bản đơn giản để minh họa khái niệm này bằng cách sử dụng một tổ chức tài chính. Một ngân hàng đã quyết định hợp nhất tài khoản cho tất cả khách hàng của mình trên một cơ sở dữ liệu duy nhất và các Giao dịch bảng là một bảng được phân vùng duy nhất chứa tất cả các giao dịch cũng như Khách hàng bảng để lưu trữ tất cả các khách hàng của ngân hàng. Ngân hàng có trụ sở tại một số quốc gia và cũng đang mở rộng. Mỗi quốc gia được xác định bởi một AffiliateID cột. Công ty được cấu trúc để quyền truy cập vào các bảng chính bị hạn chế dựa trên thâm niên.

Xác định phần bảo mật

Chúng tôi sẽ cần triển khai giải pháp Bảo mật cấp độ hàng hạn chế quyền truy cập vào dữ liệu giao dịch và khách hàng dựa trên vai trò và chính sách Bảo mật cấp độ hàng. Bước đầu tiên của chúng tôi là tạo các bảng cần thiết. Liệt kê 1 hiển thị DDL cho các bảng chính mà chúng ta sẽ kiểm tra. Toàn bộ cơ sở dữ liệu được sử dụng cho bài kiểm tra này có thể được tải xuống từ đây.

Listing 1 – Core Tables in West African Commercial Bank Database;
-- Customers;
create table Customers
(CustID int identity (1000,1) not null Primary Key
,FirstName varchar(100)
,LastName varchar(100)
,PhoneNo bigint
,ContactAddress varchar(4000)
,AffiliateID char(3) foreign key references Affiliates(AffiliateID)
,AccountNo1 bigint
,AccountNo2 bigint
,AccountNo3 bigint
,AccountNo1Curr char (3)
,AccountNo2Curr char (3)
,AccountNo3Curr char (3)
)
GO

-- Transactions;
create table Transactions
(TranID int identity (1000,1) not null 
,AcctID int foreign key references Accounts (AcctID)
,TranDate datetime 
,TranAmt money
,AffiliateID char(3) foreign key references Affiliates(AffiliateID)
,primary key (TranID,TranDate))
ON PartSch (TranDate)

-- Transaction_History;
create table Transaction_History
(TranID int identity (1000,1) not null 
,AcctID int foreign key references Accounts (AcctID)
,TranDate datetime 
,TranAmt money
,AffiliateID char(3) foreign key references Affiliates(AffiliateID)
,primary key (TranID,TranDate))
ON PartSch (TranDate)

Sau đó, chúng tôi tạo một tập hợp các bảng mà chúng tôi có thể sử dụng để xác định nhân viên. Trong thiết lập này, mỗi nhân viên có một ScopeID xác định mức độ mà người đó có thể xem hoặc thao tác dữ liệu:

1. Quốc gia - Nhân viên chỉ có thể thao tác dữ liệu ở quốc gia của nhân viên đó (nơi họ làm việc)
2. Khu vực - Nhân viên chỉ có thể thao tác dữ liệu trong khu vực của nhân viên đó (ví dụ:Tây Phi)
3. Toàn cầu - Nhân viên có thể thao tác dữ liệu ở bất kỳ quốc gia nào mà ngân hàng sẽ có chi nhánh

Mỗi phạm vi được giao cho nhân viên dựa trên sự chỉ định của họ. Phạm vi của Người quản lý nhóm là Toàn cầu , phạm vi của Quản lý quốc gia là Khu vực và phạm vi của Giám đốc điều hành là Quốc gia . Cách truyền thống để hạn chế quyền truy cập vào dữ liệu thường là sử dụng các vai trò và quyền. Chỉ định quyền cho một vai trò và sau đó chỉ định vai trò đó cho người dùng có nghĩa là người dùng có các quyền được liên kết với vai trò đó cho toàn bộ tập dữ liệu trong bảng được đề cập. Bảo mật cấp độ hàng cho chúng tôi cơ hội để làm điều gì đó chi tiết hơn:hạn chế quyền CHỌN / CẬP NHẬT / XÓA của người dùng đối với một tập hợp con của tập dữ liệu trong bảng (kiểm soát truy cập chi tiết).

Hình. 1. Bảng nhân viên và Bảng nhân viên

Vai trò và người dùng cơ sở dữ liệu

Liệt kê 2 cho thấy những người dùng và vai trò mà chúng tôi phải tạo để tiếp tục với giải pháp của mình. Ý tưởng là có một mối quan hệ giữa các nhân viên như được lưu trữ trong bảng người dùng Nhân viên và StaffScope và Hiệu trưởng Cơ sở dữ liệu mà những nhân viên này cuối cùng sẽ sử dụng để truy cập dữ liệu. Quan sát cột trong Hình 1 có tên là DBUserID . Cột này được điền bằng hàm DATABASE_PRINCIPAL_ID (xem Liệt kê 2)

Listing 2 – Staff, Database User IDs and Roles

-- Populate Staff Table
use WACB
go
insert into Staff values ('John','Edu',DATABASE_PRINCIPAL_ID(),'Manager','233205678493','2','Accra, Ghana','EGH');
insert into Staff values ('Margaret','Harrison',DATABASE_PRINCIPAL_ID(),'Group Manager','2348030006574','3','Lagos, Nigeria','ENG');
insert into Staff values ('Edward','Antwi',DATABASE_PRINCIPAL_ID(),'Executive','22824567493','1','Lome, Togo','ETG');
insert into Staff values ('Barbara','Orji',DATABASE_PRINCIPAL_ID(),'Executive','22424567493','1','Abuja, Nigeria','ENG');
GO

-- Create Database User IDs for Staff
create user jedu without login;
create user mharrison without login;
create user eantwi without login;
create user borji without login;

-- Associate Database Principal IDs with Staff
update staff set DBUserID=DATABASE_PRINCIPAL_ID(concat(left(firstname,1),lastname));


-- Create Database Roles
create role [National] ;
create role [Regional] ;
create role [Global] ;

-- Grant Permissions on Desired Tables to Database Roles
grant select on customers to [National];
grant select, update on customers to Regional;
grant select, update on customers to Global;
grant select on Transactions to Regional, Global;
grant select on Transaction_History to Regional, Global;
grant update on Transactions to Global;


-- Grant Database Roles to Database Users Associated with Staff
alter role [National] add member eantwi;
alter role [National] add member borji;
alter role [Regional] add member jedu;
alter role [Global] add member mharrison;

Tóm lại cho đến nay những gì chúng tôi đã làm là:

1. Tạo / xác định các bảng mà chúng tôi cần bảo mật
2. Tạo các bảng chỉ ra các tiêu chí mà chúng tôi sẽ sử dụng để hạn chế quyền truy cập vào dữ liệu ở cấp hàng (Phạm vi)
3. Các vai trò và người dùng cơ sở dữ liệu đã tạo, chúng tôi sẽ áp dụng các hạn chế đối với
4. Quyền truy cập có giới hạn vào các bảng chính (“Bảo mật cấp bảng”) bằng cách sử dụng vai trò và quyền

Chức năng dự đoán và Chính sách bảo mật

Cho đến nay, chúng tôi có cái mà chúng tôi có thể gọi là Bảo mật cấp bảng được triển khai bằng cách sử dụng các vai trò và quyền. Bây giờ chúng tôi muốn đi sâu hơn. Chúng tôi muốn hai hiệu trưởng có đặc quyền CHỌN trên bảng có thể truy vấn bảng nhưng xem các tập dữ liệu khác nhau dựa trên các điều kiện mà chúng tôi thiết lập. Liệt kê 3 cho chúng tôi thấy cách chúng tôi đạt được điều này.

Listing 3 - Implement Row Level Security

-- Create Predicate Function
create schema rls;
go

create function rls.AccessPredicate (@AffiliateID char(3))
returns table
with schemabinding
as
return select 1 as access 
from dbo.Staff as s 
join dbo.StaffScope ss on s.ScopeID=ss.ScopeID 
join dbo.Affiliates a on s.AffiliateID=a.AffiliateID
where (
IS_MEMBER('National')=1
and s.DBUserID=DATABASE_PRINCIPAL_ID()
and @AffiliateID=s.AffiliateID
)
OR
(
IS_MEMBER('Regional')=1
and @AffiliateID in (select a.AffiliateID from dbo.Affiliates where Region='West Africa')
)
OR
(
IS_MEMBER('Global')=1
);
GO

-- Create Security Policy
create security policy rls.dataSecurityPol
add filter predicate rls.AccessPredicate (AffiliateID) on dbo.Customers,
add filter predicate rls.AccessPredicate (AffiliateID) on dbo.Transactions,
add filter predicate rls.AccessPredicate (AffiliateID) on dbo.Transaction_History,
add block predicate rls.AccessPredicate (AffiliateID) on dbo.Customers after update,
add block predicate rls.AccessPredicate (AffiliateID) on dbo.Transactions after update,
add block predicate rls.AccessPredicate (AffiliateID) on dbo.Transaction_History after update;
GO

-- Alter Security Policy
alter security policy rls.dataSecurityPol
add filter predicate rls.AccessPredicate (AffiliateID) on dbo.Transaction_History,
add block predicate rls.AccessPredicate (AffiliateID) on dbo.Transaction_History after update;
GO

Hàm vị từ xác định các điều kiện cần phải đáp ứng để một hàm chính có thể nhìn thấy một tập hợp con của dữ liệu thú vị. Trong chức năng này, có ba điều kiện:

1. Người dùng cơ sở dữ liệu của Nhân viên là thành viên của National vai trò và AffiliateID khớp với nhân viên HOẶC
2. Người dùng cơ sở dữ liệu của Nhân viên là thành viên của Khu vực vai trò và AffiliateID khớp với danh sách AffiliateID Thuộc Khu vực Tây Phi HOẶC
3. Người dùng cơ sở dữ liệu của Nhân viên là thành viên của Toàn cầu

Điều này ngụ ý rằng một thành viên của Toàn cầu vai trò xem tất cả dữ liệu đơn giản bởi vì anh ta hoặc cô ta thuộc về vai trò đó. Tuy nhiên, các thành viên của hai vai trò còn lại phải đáp ứng các tiêu chí bổ sung liên quan đến AffiliateIDs .

Để hàm hữu ích, hãy áp dụng điều này cho các bảng dưới dạng vị từ LỌC hoặc vị từ KHỐI. Các vị từ FILTER hạn chế những gì người đứng đầu có thể nhìn thấy trong khi các vị từ BLOCK đảm bảo rằng người dùng chính không thể thao tác bất kỳ dữ liệu nào bên ngoài dữ liệu được hiển thị cho anh ta / cô ta bởi các hạn chế được xác định trong hàm. Chính sách bảo mật là một vùng chứa trong đó chúng tôi chỉ định các vị từ FILTER và BLOCK cho tất cả các bảng mà chúng tôi quan tâm. Hãy xem qua Liệt kê 3 một lần nữa.

Một khía cạnh rất thú vị của phương pháp này là tính mô-đun. Chúng ta có thể áp dụng các vị từ cho các bảng bổ sung trong Chính sách bảo mật mà không ảnh hưởng đến các bảng đã định nghĩa hiện có, chúng ta có thể thêm các nguyên tắc cơ sở dữ liệu mới (Nhân viên) bằng cách tạo người dùng cơ sở dữ liệu và cấp cho họ các vai trò thích hợp. Khi sự điều động của Nhân viên diễn ra, chúng tôi có thể cập nhật các nhiệm vụ vai trò, v.v.

Kiểm tra việc triển khai

Vì vậy, bây giờ chúng ta đã hoàn tất, chúng ta có thể mạo danh các nguyên tắc cơ sở dữ liệu để xác định xem chúng ta có kết quả mong đợi hay không bằng cách sử dụng mã trong Liệt kê 4. Trước khi xem xét điều đó, hãy xem các vai trò liên quan đến từng nhân viên và các chi nhánh của họ trong Hình 2.

Hình. 2. Danh sách nhân viên

Listing 4 – Testing the Implementation

select * from Customers;
execute ('select * from Customers') as user='eantwi';
execute ('select * from Customers') as user='borji';
execute ('select * from Customers') as user='jedu';
execute ('select * from Customers') as user='mharrison';

Trong dòng đầu tiên, tôi truy vấn Khách hàng bảng dưới dạng sysadmin, nhưng tôi KHÔNG nhận được ROWS. Có nghĩa là ngay cả quản trị viên cũng không thể ghi đè các tác động của RLS nếu không mạo danh.

Hình. 4. SysAdmin không thấy hàng nào

Barbara và Edward đều là Giám đốc điều hành và thuộc Phạm vi Quốc gia nhưng họ làm việc ở các quốc gia khác nhau nên họ thấy Khách hàng được liên kết với các chi nhánh tương ứng của họ. (Xem Tên nhân viên trong Hình 1).

Hình. 5. Giám đốc điều hành xem Hàng của Đơn vị liên kết của họ

John và Margaret là Giám đốc Quốc gia và Nhóm. Họ thuộc về Khu vực và Toàn cầu Phạm vi tương ứng. John xem dữ liệu cho Tây Phi, trong khi Margaret xem dữ liệu cho tất cả các khu vực.

Hình. 6. Người quản lý xem Hàng trong khu vực của họ

Kết quả giống nhau đối với tất cả các bảng khác mà Chính sách bảo mật đã được áp dụng. Tuân thủ điều đó mà không có quyền đối với Giao dịch bảng, Bảo mật mức hàng không có giá trị.

Hình. 7. Không có quyền SELECT trên Giao dịch Bảng

Listing 5 – Permissions on Transactions Table
grant select on dbo.Transactions to [National];

Hình. 8. Giao dịch Bảng do Giám đốc điều hành đã nhìn thấy

Kết luận

Row Level Security là một phương pháp mạnh mẽ để khai thác khả năng kiểm soát truy cập chi tiết của SQL Server. Sử dụng tính năng này yêu cầu bạn đang chạy SQL Server 2016 trở lên. Như tên của nó, mục tiêu là hạn chế quyền truy cập vào các hàng trong bảng bằng cách sử dụng các truy vấn phức tạp sau khi bạn đã quan tâm đến "bảo mật cấp bảng". Các tình huống mà khả năng này có thể được áp dụng là vô tận, do đó nó rất hữu ích cho nhiều loại môi trường. Hãy làm tốt để khám phá và xem nó có thể làm gì cho bạn.

Tài liệu tham khảo

Isakov, V. (2018). Bài kiểm tra tham khảo 70-764 Quản trị cơ sở hạ tầng cơ sở dữ liệu SQL . Giáo dục Pearson

Bảo mật cấp hàng