แชร์ผ่าน

การรักษาความปลอดภัยระดับแถวในคลังข้อมูล Fabric

  • บทความ

นําไปใช้กับ:✅ จุดสิ้นสุดการวิเคราะห์ SQL และ Warehouse ใน Microsoft Fabric

การรักษาความปลอดภัยระดับแถว (RLS) ช่วยให้คุณสามารถใช้การเป็นสมาชิกกลุ่มหรือบริบทการดําเนินการเพื่อควบคุมการเข้าถึงแถวในตารางฐานข้อมูล ตัวอย่างเช่น คุณสามารถตรวจสอบให้แน่ใจว่าผู้ปฏิบัติงานเข้าถึงเฉพาะแถวข้อมูลเหล่านั้นที่เกี่ยวข้องกับแผนกของพวกเขาเท่านั้น อีกตัวอย่างหนึ่งคือการจํากัดการเข้าถึงข้อมูลของลูกค้าให้เหลือเพียงข้อมูลที่เกี่ยวข้องกับบริษัทของตนในสถาปัตยกรรมแบบหลายผู้เช่า คุณลักษณะนี้จะคล้ายกับการรักษาความปลอดภัยระดับแถวใน SQL Server

การรักษาความปลอดภัยระดับแถวในระดับข้อมูล

การรักษาความปลอดภัยระดับแถวช่วยให้การออกแบบและการเขียนโค้ดของความปลอดภัยในแอปพลิเคชันของคุณง่ายขึ้น การรักษาความปลอดภัยระดับแถวช่วยให้คุณใช้ข้อจํากัดในการเข้าถึงแถวข้อมูล

ตรรกะข้อจํากัดการเข้าถึงอยู่ในระดับฐานข้อมูล ไม่ได้อยู่ในระดับแอปพลิเคชันเดียว ฐานข้อมูลใช้ข้อจํากัดการเข้าถึงทุกครั้งที่มีการพยายามเข้าถึงข้อมูล จากแอปพลิเคชันหรือแพลตฟอร์มการรายงานใดๆ รวมถึง Power BI จึงทําให้ระบบรักษาความปลอดภัยของคุณเชื่อถือได้และทนทานมากขึ้นโดยการลดพื้นที่ผิวหน้าของระบบรักษาความปลอดภัยของคุณ การรักษาความปลอดภัยระดับแถวใช้กับคิวรีบน Warehouse หรือจุดสิ้นสุดการวิเคราะห์ SQL ใน Fabric เท่านั้น คิวรี Power BI บนคลังสินค้าในโหมด Direct Lake จะย้อนกลับไปยังโหมด Direct Query เพื่อปฏิบัติตามการรักษาความปลอดภัยระดับแถว

จํากัดการเข้าถึงแถวบางแถวให้กับผู้ใช้บางราย

ใช้ RLS โดยใช้คําสั่ง CREATE SECURITY POLICY Transact-SQL และเพรดิเคตที่สร้างขึ้นเป็น ฟังก์ชันที่ให้ค่าตารางแบบอินไลน์

การรักษาความปลอดภัยระดับแถวถูกนําไปใช้กับ คลังสินค้าที่ใช้ร่วมกันหรือเลคเฮ้าส์เนื่องจากแหล่งข้อมูลพื้นฐานไม่ได้เปลี่ยนแปลง

การรักษาความปลอดภัยระดับแถวตามเพรดิเคต

การรักษาความปลอดภัยระดับแถวใน Fabric Synapse Data Warehouse รองรับการรักษาความปลอดภัยตามเพรดิเคต เพรดิเคตตัวกรองแบบเงียบกรองแถวที่พร้อมใช้งานสําหรับการอ่านการดําเนินการ

การเข้าถึงข้อมูลระดับแถวในตารางจะถูกจํากัดโดยเพรดิเคตความปลอดภัยที่กําหนดเป็นฟังก์ชันค่าตารางแบบอินไลน์ จากนั้น ฟังก์ชันจะถูกเรียกใช้และบังคับใช้โดยนโยบายความปลอดภัย สําหรับเพรดิเคตตัวกรอง แอปพลิเคชันไม่ทราบแถวที่ถูกกรองจากชุดผลลัพธ์ ถ้ามีการกรองแถวทั้งหมด ระบบจะแสดงชุด null

เพรดิเคตตัวกรองจะถูกนําไปใช้ขณะอ่านข้อมูลจากตารางฐาน ซึ่งจะส่งผลกระทบต่อการดําเนินการรับทั้งหมด: SELECT, DELETEและUPDATE แต่ละตารางต้องมีความปลอดภัยระดับแถวของตนเองที่กําหนดไว้แยกต่างหาก ผู้ใช้ที่สอบถามตารางโดยไม่มีนโยบายความปลอดภัยระดับแถวจะดูข้อมูลที่ไม่ได้การกรอง

ผู้ใช้ไม่สามารถเลือกหรือลบแถวที่ถูกกรองได้ ผู้ใช้ไม่สามารถอัปเดตแถวที่มีการกรองได้ แต่เป็นไปได้ที่จะอัปเดตแถวในลักษณะที่จะถูกกรองในภายหลัง

เพรดิเคตตัวกรองและนโยบายการรักษาความปลอดภัยมีลักษณะการทํางานต่อไปนี้:

  • คุณสามารถกําหนดฟังก์ชันเพรดิเคตที่รวมกับตารางอื่นและ/หรือเรียกใช้ฟังก์ชัน ถ้ามีการสร้างนโยบายความปลอดภัยด้วย SCHEMABINDING = ON (ค่าเริ่มต้น) แล้วการรวมหรือฟังก์ชันจะสามารถเข้าถึงได้จากคิวรี และทํางานตามที่คาดไว้โดยไม่มีการตรวจสอบสิทธิ์เพิ่มเติม

  • คุณสามารถออกคิวรีกับตารางที่มีการกําหนดเพรดิเคตความปลอดภัยแต่ปิดใช้งานได้ แถวใด ๆ ที่ถูกกรองหรือบล็อกจะไม่ได้รับผลกระทบ

  • ถ้าผู้ใช้ dbo สมาชิกของ db_owner บทบาท หรือเจ้าของตารางคิวรีตารางที่มีนโยบายความปลอดภัยที่กําหนดและเปิดใช้งาน แถวจะถูกกรองหรือบล็อกตามที่กําหนดโดยนโยบายความปลอดภัย

  • ความพยายามที่จะเปลี่ยนแปลง Schema ของตารางที่ผูกไว้โดยนโยบายความปลอดภัยที่ผูกกับ Schema จะส่งผลให้เกิดข้อผิดพลาด อย่างไรก็ตาม คอลัมน์ที่ไม่ได้อ้างอิงโดยเพรดิเคตสามารถเปลี่ยนแปลงได้

  • ความพยายามที่จะเพิ่มเพรดิเคตบนตารางที่กําหนดไว้แล้วสําหรับการดําเนินการที่ระบุส่งผลให้เกิดข้อผิดพลาด ซึ่งจะเกิดขึ้นไม่ว่าจะเปิดใช้งานเพรดิเคตหรือไม่

  • ความพยายามที่จะปรับเปลี่ยนฟังก์ชันที่ใช้เป็นเพรดิเคตในตารางภายในนโยบายความปลอดภัยที่ผูกไว้ของ Schema จะส่งผลให้เกิดข้อผิดพลาด

  • การกําหนดนโยบายความปลอดภัยที่ใช้งานอยู่หลายรายการที่มีเพรดิเคตที่ไม่ซ้อนทับกันจะประสบความสําเร็จ

เพรดิเคตตัวกรองมีลักษณะการทํางานต่อไปนี้:

  • กําหนดนโยบายความปลอดภัยที่กรองแถวของตาราง แอปพลิเคชันไม่ทราบแถวใดๆ ที่มีการกรองสําหรับ SELECTUPDATE, และ DELETE การดําเนินการ รวมถึงสถานการณ์ที่มีการกรองแถวทั้งหมด แอปพลิเคชันสามารถ INSERT แถวแม้ว่าจะถูกกรองในระหว่างการดําเนินการอื่น ๆ

การอนุญาต

การสร้าง เปลี่ยน หรือปล่อยนโยบายความปลอดภัยต้องการสิทธิ์ALTER ANY SECURITY POLICY การสร้างหรือการวางนโยบายความปลอดภัยจําเป็นต้องมี ALTER สิทธิ์บน Schema

นอกจากนี้ จําเป็นต้องมีสิทธิ์ต่อไปนี้สําหรับแต่ละเพรดิเคตที่เพิ่ม:

  • SELECT และ REFERENCES สิทธิ์บนฟังก์ชันที่ใช้เป็นเพรดิเคต

  • REFERENCES สิทธิ์บนตารางเป้าหมายที่จะผูกกับนโยบาย

  • REFERENCES สิทธิ์บนทุกคอลัมน์จากตารางเป้าหมายที่ใช้เป็นอาร์กิวเมนต์

นโยบายความปลอดภัยนําไปใช้กับผู้ใช้ทั้งหมด รวมถึงผู้ใช้ dbo ในฐานข้อมูล ผู้ใช้ Dbo สามารถเปลี่ยนแปลงหรือลดนโยบายความปลอดภัยได้ แต่การเปลี่ยนแปลงนโยบายความปลอดภัยสามารถตรวจสอบได้ ถ้าสมาชิกของบทบาทเช่นผู้ดูแลระบบ สมาชิก หรือผู้สนับสนุนจําเป็นต้องดูแถวทั้งหมดเพื่อแก้ไขปัญหาหรือตรวจสอบข้อมูล ต้องเขียนนโยบายความปลอดภัยเพื่ออนุญาต

ถ้ามีการสร้างนโยบายความปลอดภัยด้วย SCHEMABINDING = OFFเพื่อคิวรีตารางเป้าหมาย ผู้ใช้ต้องมีสิทธิ์ SELECT หรือ EXECUTE บนฟังก์ชันเพรดิเคตและตาราง มุมมอง หรือฟังก์ชันเพิ่มเติมใด ๆ ที่ใช้ภายในฟังก์ชันเพรดิเคต ถ้ามีการสร้างนโยบายความปลอดภัยด้วย SCHEMABINDING = ON (ค่าเริ่มต้น) การตรวจสอบสิทธิ์เหล่านี้จะถูกบายพาสเมื่อผู้ใช้คิวรีตารางเป้าหมาย

ข้อควรพิจารณาด้านความปลอดภัย: การโจมตีช่องทางด้านข้าง

พิจารณาและเตรียมพร้อมสําหรับสองสถานการณ์ต่อไปนี้

ตัวจัดการนโยบายความปลอดภัยที่เป็นอันตราย

สิ่งสําคัญคือต้องสังเกตว่า ผู้จัดการนโยบายความปลอดภัยที่เป็นอันตราย ที่มีสิทธิ์เพียงพอในการสร้างนโยบายความปลอดภัยที่ด้านบนของคอลัมน์ที่ละเอียดอ่อน และมีสิทธิ์ในการสร้างหรือเปลี่ยนแปลงฟังก์ชันที่มีค่าตารางแบบอินไลน์ สามารถปะทะกับผู้ใช้รายอื่นที่มีสิทธิ์บนตารางเพื่อดําเนินการวิเคราะห์ข้อมูลโดยการสร้างฟังก์ชันที่มีค่าตารางแบบอินไลน์ที่ออกแบบมาเพื่อใช้การโจมตีช่องด้านข้างเพื่อทําให้ข้อมูลถูกละเมิด การโจมตีดังกล่าวจะต้องขัดแย้ง (หรือสิทธิ์ที่มากเกินไปที่มอบให้กับผู้ใช้ที่เป็นอันตราย) และอาจต้องมีการทําซ้ําหลายครั้งในการปรับเปลี่ยนนโยบาย (จําเป็นต้องมีสิทธิ์ในการลบเพรดิเคตเพื่อแบ่งการผูก Schema) การปรับเปลี่ยนฟังก์ชันที่มีค่าในตารางแบบอินไลน์และเรียกใช้คําสั่งที่เลือกซ้ํา ๆ บนตารางเป้าหมาย เราขอแนะนําให้คุณจํากัดสิทธิ์ตามที่จําเป็นและตรวจสอบกิจกรรมที่น่าสงสัย กิจกรรมเช่นการเปลี่ยนแปลงนโยบายอย่างต่อเนื่องและควรตรวจสอบฟังก์ชันที่มีค่าตารางแบบอินไลน์ที่เกี่ยวข้องกับการรักษาความปลอดภัยระดับแถว

คิวรีที่สร้างขึ้นอย่างระมัดระวัง

เป็นไปได้ที่จะทําให้เกิดการรั่วไหลของข้อมูลโดยใช้คิวรีที่สร้างขึ้นอย่างระมัดระวังที่ใช้ข้อผิดพลาดเพื่อแทรกซึมข้อมูล ตัวอย่างเช่น SELECT 1/(SALARY-100000) FROM PAYROLL WHERE NAME='John Doe'; จะทําให้ผู้ใช้ที่เป็นอันตรายทราบว่าเงินเดือนของ John Doe มีมูลค่า 100,000 ดอลลาร์สหรัฐ แม้ว่าจะมีเพรดิเคตความปลอดภัยเพื่อป้องกันไม่ให้ผู้ใช้ที่เป็นอันตรายสอบถามเงินเดือนของบุคคลอื่นโดยตรง ผู้ใช้สามารถกําหนดได้ว่าคิวรีจะส่งกลับข้อยกเว้นการหารด้วยศูนย์เมื่อใด

ตัวอย่าง

เราสามารถสาธิตจุดสิ้นสุดของคลังการรักษาความปลอดภัยระดับแถวและจุดสิ้นสุดการวิเคราะห์ SQL ใน Microsoft Fabric ได้

ตัวอย่างต่อไปนี้สร้างตารางตัวอย่างที่จะทํางานกับ Warehouse ใน Fabric แต่ในปลายทางการวิเคราะห์ SQL จะใช้ตารางที่มีอยู่ ในจุดสิ้นสุดการวิเคราะห์ SQL คุณไม่สามารถ CREATE TABLEแต่คุณสามารถ CREATE SCHEMA, CREATE FUNCTIONและ CREATE SECURITY POLICYได้

ในตัวอย่างนี้ ก่อนอื่นให้สร้าง Schema salesตารางsales.Orders

CREATE SCHEMA sales;
GO

-- Create a table to store sales data
CREATE TABLE sales.Orders (
    SaleID INT,
    SalesRep VARCHAR(100),
    ProductName VARCHAR(50),
    SaleAmount DECIMAL(10, 2),
    SaleDate DATE
);

-- Insert sample data
INSERT INTO sales.Orders (SaleID, SalesRep, ProductName, SaleAmount, SaleDate)
VALUES
    (1, 'Sales1@contoso.com', 'Smartphone', 500.00, '2023-08-01'),
    (2, 'Sales2@contoso.com', 'Laptop', 1000.00, '2023-08-02'),
    (3, 'Sales1@contoso.com', 'Headphones', 120.00, '2023-08-03'),
    (4, 'Sales2@contoso.com', 'Tablet', 800.00, '2023-08-04'),
    (5, 'Sales1@contoso.com', 'Smartwatch', 300.00, '2023-08-05'),
    (6, 'Sales2@contoso.com', 'Gaming Console', 400.00, '2023-08-06'),
    (7, 'Sales1@contoso.com', 'TV', 700.00, '2023-08-07'),
    (8, 'Sales2@contoso.com', 'Wireless Earbuds', 150.00, '2023-08-08'),
    (9, 'Sales1@contoso.com', 'Fitness Tracker', 80.00, '2023-08-09'),
    (10, 'Sales2@contoso.com', 'Camera', 600.00, '2023-08-10');

สร้าง Security สคีมา ฟังก์ชัน Security.tvf_securitypredicateและนโยบาย SalesFilterความปลอดภัย

-- Creating schema for Security
CREATE SCHEMA Security;
GO
 
-- Creating a function for the SalesRep evaluation
CREATE FUNCTION Security.tvf_securitypredicate(@SalesRep AS nvarchar(50))
    RETURNS TABLE
WITH SCHEMABINDING
AS
    RETURN SELECT 1 AS tvf_securitypredicate_result
WHERE @SalesRep = USER_NAME() OR USER_NAME() = 'manager@contoso.com';
GO
 
-- Using the function to create a Security Policy
CREATE SECURITY POLICY SalesFilter
ADD FILTER PREDICATE Security.tvf_securitypredicate(SalesRep)
ON sales.Orders
WITH (STATE = ON);
GO

หากต้องการปรับเปลี่ยนฟังก์ชันการรักษาความปลอดภัยระดับแถว คุณต้องปล่อยนโยบายความปลอดภัยก่อน ในสคริปต์ต่อไปนี้ เราจะปล่อยนโยบายSalesFilterก่อนออกALTER FUNCTIONคําสั่งบนSecurity.tvf_securitypredicate จากนั้น เราจะสร้างนโยบาย SalesFilterใหม่

-- Drop policy so we can change the predicate function.
DROP SECURITY POLICY SalesFilter;
GO

-- Alter the function for the SalesRep evaluation
ALTER FUNCTION Security.tvf_securitypredicate(@SalesRep AS nvarchar(50))
    RETURNS TABLE
WITH SCHEMABINDING
AS
    RETURN SELECT 1 AS tvf_securitypredicate_result
WHERE @SalesRep = USER_NAME() OR USER_NAME() = 'president@contoso.com';
GO
 
-- Re-create a Security Policy
CREATE SECURITY POLICY SalesFilter
ADD FILTER PREDICATE Security.tvf_securitypredicate(SalesRep)
ON sales.Orders
WITH (STATE = ON);
GO

ขั้นตอนถัดไป

ใช้การรักษาความปลอดภัยระดับแถวในคลังสินค้าข้อมูล Fabric

เนื้อหาที่เกี่ยวข้อง