เพิ่มการปกป้องข้อมูลด้วย Row-Level Security ใน SQL Server 2016

บทนำ

Microsoft® มุ่งเน้น Security ใน SQL Server® เกือบทุก Release มีการปรับปรุงหรือเพิ่ม Security Features ใหม่ ใน SQL Server 2016 มี Features ใหม่หลายอย่างช่วยปกป้องข้อมูล รวมถึง Row-Level Security (RLS), Always Encrypted, และ Dynamic Data Masking

ใน Blog ก่อนหน้าเขียนถึง Dynamic Data Masking ใน SQL Server 2016 บทนี้แนะนำ Row-Level Security (RLS) ซึ่งควบคุมว่า User ไหนเข้าถึง Row ไหนใน Table ได้ RLS ให้คุณ Implement การจำกัดข้อมูลตามลักษณะของ User ที่รัน Query ช่วยควบคุมการเข้าถึงข้อมูลได้ง่ายและโปร่งใสสำหรับ User ต่างๆ

ความจำเป็นของ RLS

มีครั้งที่ต้อง Return ข้อมูลเฉพาะให้ User เฉพาะ ในอดีตทำด้วยการสร้าง View และ Grant Select Permission บน View แต่ Approach นั้นกลายเป็น Unmanageable เมื่อจำนวน View และ User เพิ่มขึ้น Microsoft จึงนำ RLS มาแก้ปัญหา Security ในสถานการณ์ใหม่

RLS ให้ Fine-grained Control Over Access to Rows ช่วยควบคุมว่า User ไหนเห็นข้อมูลไหนได้ โดยโปร่งใสต่อ Application

ด้วย Feature นี้ Row ถูก Filter ตาม Execution Context ของ Query ไม่ใช่ Current User Access Rights คุณสามารถสร้าง Secure Logic Rules กำหนดว่า User ไหนเห็น Row ไหน และจำกัด Row/Data ใดๆ โดยออกแบบ Security Policy ที่ยืดหยุ่นและแข็งแกร่งสำหรับ Table

Image Source: https://sqlwithmanoj.com/2015/07/13/implementing-row-level-security-rls-with-sql-server-2016/

คุณสมบัติของ RLS

• Fine-grained Access Role (ควบคุม Read และ Write Access ต่อ Row เฉพาะ)
• Application Transparency (ไม่ต้องแก้ไข Application)
• Centralize Access ภายใน Database
• ง่ายต่อการ Implement และ Maintain

RLS ทำงานอย่างไร

เพื่อ Implement RLS ต้องพิจารณา 3 Elements:

• Predicate Function
• Security Predicates
• Security Policy

Predicate Function

เป็น Inline Table-valued Function ที่ตรวจสอบว่า User ที่รัน Query มีสิทธิ์เข้าถึงข้อมูลตาม Logic ที่กำหนดหรือไม่ Function คืนค่า 1 สำหรับ Row ที่ User ได้รับอนุญาต

Security Predicates

ช่วย Bind Predicate Function เข้ากับ Table RLS รองรับ 2 ประเภท:

• Filter Predicates: Filter ข้อมูลเงียบๆ โดยไม่ Raise Error สำหรับ Operation ต่อไป ตาม Logic ใน Predicate Function: SELECT, UPDATE, DELETE
• Block Predicates: Raise Error อย่างชัดเจนและ Block User จาก Operation ต่อไปบน Data ที่ฝ่าฝืน Predicate Function Logic: AFTER INSERT, AFTER UPDATE, BEFORE UPDATE, BEFORE DELETE

Security Policy

Security Policy Object ถูกสร้างขึ้นเพื่อ Group Security Predicates ทั้งหมดที่อ้างอิง Predicate Function เดียวกัน

Use Cases

ตัวอย่างการออกแบบ RLS:

• โรงพยาบาล: สร้าง Policy ให้พยาบาลเห็น Row ของผู้ป่วยที่ตัวเองดูแลเท่านั้น
• ธนาคาร: จำกัดการเข้าถึง Row ข้อมูลทางการเงินตาม Division หรือ Role ของพนักงาน
• Multi-tenant App: บังคับ Logical Separation ของ Row ข้อมูลแต่ละ Tenant เนื่องจากหลาย Tenant เก็บใน Table เดียวกัน กระบวนการจึงมีประสิทธิภาพ Tenant แต่ละอันเห็น Row ของตัวเองเท่านั้น

Implement RLS (ตัวอย่าง)

Step 1: สร้าง Database RowFilter และ User 2 คน

CREATE DATABASE RowFilter; GO
USE RowFilter; GO
CREATE USER userBrian WITHOUT LOGIN;
CREATE USER userJames WITHOUT LOGIN; GO

Step 2: สร้าง Table และ Grant SELECT

CREATE TABLE dbo.SalesFigures (
    [userCode] NVARCHAR(10),
    [sales] MONEY) GO
INSERT INTO dbo.SalesFigures VALUES ('userBrian',100), ('userJames',250), ('userBrian',350) GO
GRANT SELECT ON dbo.SalesFigures TO userBrian;
GRANT SELECT ON dbo.SalesFigures TO userJames; GO

Step 3: เพิ่ม Filter Predicate Function

CREATE FUNCTION dbo.rowLevelPredicate (@userCode as sysname)
RETURNS TABLE
WITH SCHEMABINDING AS
RETURN SELECT 1 AS rowLevelPredicateResult WHERE @userCode = USER_NAME(); GO

Step 4: เพิ่ม Filter Predicate ให้ Table dbo.SalesFigures

CREATE SECURITY POLICY UserFilter
ADD FILTER PREDICATE dbo.rowLevelPredicate(userCode) ON dbo.SalesFigures
WITH (STATE = ON); GO

Step 5: ทดสอบด้วย User ที่สร้าง

EXECUTE AS USER = 'userBrian';
SELECT * FROM dbo.SalesFigures;
REVERT; GO

คืนค่า 2 Rows (ของ userBrian)

EXECUTE AS USER = 'userJames';
SELECT * FROM dbo.SalesFigures;
REVERT; GO

คืนค่า 1 Row (ของ userJames)

Permissions

• Create/Alter/Drop Security Policies ต้องมี Permission ALTER ANY SECURITY POLICY
• Create/Drop Security Policy ต้องมี ALTER Permission บน Schema
• Predicate แต่ละตัวต้องการ Permission เพิ่มเติม:
  • SELECT และ REFERENCES บน Function ที่ใช้เป็น Predicate
  • REFERENCES บน Target Table ที่ Bind กับ Policy
  • REFERENCES บนทุก Column จาก Target Table ที่ใช้เป็น Argument

Security Policies บังคับใช้กับทุก User รวมถึง DBO Users DBO สามารถ Alter/Drop Policy ได้ แต่การเปลี่ยนแปลงสามารถ Audit ได้ สำหรับ High-privileged Users เช่น sysadmin หรือ db_owner ที่ต้องเห็นทุก Row เพื่อ Troubleshoot ต้องเขียน Policy ให้อนุญาต

ถ้า Policy สร้างด้วย SCHEMABINDING = OFF User ต้องมี SELECT หรือ EXECUTE บน Predicate Function และ Object อื่นๆ ที่ใช้ใน Function ถ้า SCHEMABINDING = ON (Default) Permission Checks นี้จะถูก Bypass ตอน Query Target Table