คําแนะนําการรักษาความปลอดภัยระดับแถว (RLS) ใน Power BI Desktop

บทความนี้มุ่งเป้าหมายไปยังคุณในฐานะผู้สร้างแบบจําลองข้อมูลที่ทํางานกับ Power BI Desktop ซึ่งอธิบายแนวทางปฏิบัติในการออกแบบที่ดีสําหรับการบังคับใช้การรักษาความปลอดภัยระดับแถว (RLS) ในแบบจําลองข้อมูลของคุณ

เป็นสิ่งสําคัญที่ต้องทําความเข้าใจตัวกรอง RLS แถวของตาราง สิ่งเหล่านี้ไม่สามารถกําหนดค่าให้จํากัดการเข้าถึงวัตถุของแบบจําลอง รวมถึงตาราง คอลัมน์ หรือหน่วยวัดได้

หมายเหตุ

บทความนี้ไม่ได้อธิบาย RLS หรือวิธีการตั้งค่า สําหรับข้อมูลเพิ่มเติม โปรดดู จํากัดการเข้าถึงข้อมูลด้วยการรักษาความปลอดภัยระดับแถว (RLS) สําหรับ Power BI Desktop

นอกจากนี้ยังไม่ครอบคลุมถึงการบังคับใช้ RLS ในการเชื่อมต่อแบบสดไปยังแบบจําลองที่โฮสต์ภายนอกด้วย Azure Analysis Services หรือ SQL Server Analysis Services ในกรณีเหล่านี้ RLS จะถูกบังคับใช้โดย Analysis Services เมื่อ Power BI เชื่อมต่อโดยใช้การลงชื่อเข้าระบบครั้งเดียว (SSO) Analysis Services จะบังคับใช้ RLS (เว้นแต่บัญชีจะมีสิทธิ์ของผู้ดูแลระบบ)

สร้างบทบาท

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

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

พิจารณาแบบจําลองที่มีสองบทบาท: บทบาทแรก ชื่อ ผู้ปฏิบัติงาน จํากัดการเข้าถึงแถวของตาราง บัญชีเงินเดือน ทั้งหมดโดยใช้นิพจน์ของกฎต่อไปนี้:

FALSE()

หมายเหตุ

กฎจะไม่ส่งกลับแถวของตารางเมื่อนิพจน์ประเมินเป็นFALSE

แต่บทบาทที่สองชื่อผู้จัดการอนุญาตให้เข้าถึงแถวตาราง ค่าจ้าง ทั้งหมดโดยใช้นิพจน์ของกฎต่อไปนี้:

TRUE()

ดูแล: หากผู้ใช้รายงานแมปกับบทบาททั้งสองพวกเขาจะเห็นแถวตาราง เงินเดือน ทั้งหมด

ปรับ RLS ให้เหมาะสม

RLS ทํางานโดยการนําตัวกรองไปใช้กับคิวรี DAX ทั้งหมดโดยอัตโนมัติ และตัวกรองเหล่านี้อาจมีผลกระทบเชิงลบต่อประสิทธิภาพการทํางานของคิวรี ดังนั้น RLS ที่มีประสิทธิภาพมาจากการออกแบบแบบจําลองที่ดี สิ่งสําคัญคือต้องปฏิบัติตามคําแนะนําการออกแบบแบบจําลองตามที่อธิบายไว้ในบทความต่อไปนี้:

• ทําความเข้าใจ Schema รูปดาวและความสําคัญสําหรับ Power BI
• บทความคําแนะนําของความสัมพันธ์ทั้งหมดที่พบใน เอกสารคําแนะนําของ Power BI

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

เมื่อใดก็ตามที่มีการบังคับใช้ตัวกรอง RLS ในตาราง DirectQuery และมีความสัมพันธ์กับตาราง DirectQuery อื่น ๆ ตรวจสอบให้แน่ใจว่าได้ปรับใช้ฐานข้อมูลต้นทางให้เหมาะสม ซึ่งอาจเกี่ยวข้องกับการออกแบบดัชนีที่เหมาะสมหรือใช้คอลัมน์ที่มีการคํานวณอยู่ สําหรับข้อมูลเพิ่มเติม โปรดดูคําแนะนําแบบจําลอง DirectQuery ใน Power BI Desktop

วัดผลกระทบ RLS

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

กําหนดค่าการแมปบทบาท

เมื่อเผยแพร่ไปยัง Power BI แล้ว คุณต้องแมปสมาชิกไปยังแบบจําลองเชิงความหมาย (ก่อนหน้านี้เรียกว่าบทบาทชุดข้อมูล) เฉพาะเจ้าของแบบจําลองความหมายหรือผู้ดูแลระบบพื้นที่ทํางานเท่านั้นที่สามารถเพิ่มสมาชิกไปยังบทบาทได้ สําหรับข้อมูลเพิ่มเติม โปรดดูการรักษาความปลอดภัยระดับแถว (RLS) ด้วย Power BI (จัดการความปลอดภัยบนแบบจําลองของคุณ)

สมาชิกสามารถเป็นบัญชีผู้ใช้ กลุ่มความปลอดภัย กลุ่มการแจกจ่าย หรือกลุ่มจดหมายที่เปิดใช้งาน เมื่อใดก็ตามที่เป็นไปได้ เราขอแนะนําให้คุณแมปกลุ่มความปลอดภัยไปยังบทบาทแบบจําลองเชิงความหมาย ซึ่งเกี่ยวข้องกับการจัดการการเป็นสมาชิกของกลุ่มความปลอดภัยใน Microsoft Entra ID (ก่อนหน้านี้เรียกว่า Azure Active Directory) อาจเป็นไปได้ว่าได้มอบหมายงานให้กับผู้ดูแลระบบเครือข่ายของคุณ

ตรวจสอบบทบาท

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

เมื่อแบบจําลองมีกฎแบบไดนามิกที่ใช้ฟังก์ชัน DAX ของ USERNAME โปรดตรวจสอบให้แน่ใจว่าได้ทดสอบค่าที่คาดไว้และที่ไม่คาดคิด เมื่อทําการฝังเนื้อหา Power BI— โดยเฉพาะโดยใช้ สถานการณ์การฝังตัวสําหรับลูกค้า ของคุณ — ตรรกะของแอปสามารถส่งผ่านค่าใดก็ได้ในฐานะชื่อผู้ใช้ข้อมูลประจําตัวที่มีประสิทธิภาพ เมื่อใดก็ตามที่เป็นไปได้ ให้ตรวจสอบให้แน่ใจว่าค่าที่ไม่ได้ตั้งใจหรือเป็นอันตรายในตัวกรองที่ส่งแถวกลับมา

พิจารณาตัวอย่างโดยใช้ Power BI embedded ซึ่งแอปจะส่งผ่านบทบาทงานของผู้ใช้เป็นชื่อผู้ใช้ที่มีประสิทธิภาพ: ซึ่งเป็น "ผู้จัดการ" หรือ "ผู้ปฏิบัติงาน" ผู้จัดการสามารถดูแถวทั้งหมดได้ แต่ผู้ปฏิบัติงานสามารถดูได้เฉพาะแถวที่ ค่าคอลัมน์ประเภท คือ "ภายใน"

มีการกําหนดนิพจน์กฎต่อไปนี้:

IF(
    USERNAME() = "Worker",
    [Type] = "Internal",
    TRUE()
)

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

IF(
    USERNAME() = "Worker",
    [Type] = "Internal",
    IF(
        USERNAME() = "Manager",
        TRUE(),
        FALSE()
    )
)

ออกแบบ RLS บางส่วน

บางครั้งการคํานวณจําเป็นต้องมีค่าที่ไม่ถูกจํากัดโดยตัวกรอง RLS ตัวอย่างเช่น รายงานอาจจําเป็นต้องแสดงอัตราส่วนของรายได้ที่ได้รับสําหรับภูมิภาคการขายของผู้ใช้รายงานในรายได้ทั้งหมดที่ได้รับ

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

มาดูกันว่าคุณสามารถใช้ข้อกําหนดการออกแบบนี้ได้อย่างไร ก่อนอื่น ให้พิจารณาการออกแบบแบบจําลองต่อไปนี้:

แบบจําลองประกอบด้วยสี่ตาราง:

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

นิพจน์ต่อไปนี้กําหนดตารางที่มีการคํานวณของ SalesRevenueSummary :

SalesRevenueSummary =
SUMMARIZECOLUMNS(
    Sales[OrderDate],
    "RevenueAllRegion", SUM(Sales[Revenue])
)

หมายเหตุ

ตารางการรวมสามารถมีความต้องการในการออกแบบเดียวกันได้

กฎ RLS ต่อไปนี้ถูกนําไปใช้กับ ตารางพนักงานขาย :

[EmailAddress] = USERNAME()

แต่ละความสัมพันธ์ของแบบจําลองสามอย่างจะอธิบายไว้ในตารางต่อไปนี้:

ความสัมพันธ์	คำอธิบาย
	มีความสัมพันธ์แบบกลุ่มต่อกลุ่มระหว่างพนักงานขายและตารางยอดขาย กฎ RLS กรองคอลัมน์ EmailAddress ของตาราง พนักงานขาย ที่ซ่อนไว้โดยใช้ฟังก์ชัน DAX ของ USERNAME ค่าคอลัมน์ภูมิภาค (สําหรับผู้ใช้รายงาน) เผยแพร่ไปยังตารางยอดขาย
	มีความสัมพันธ์แบบหนึ่งต่อกลุ่มระหว่างวันที่และตารางยอดขาย
	มีความสัมพันธ์แบบหนึ่งต่อกลุ่มระหว่าง วันที่ และ ตารางสรุป SalesRevenue

นิพจน์ต่อไปนี้กําหนด หน่วยวัด รายได้ % ของภูมิภาค ทั้งหมด:

Revenue % All Region =
DIVIDE(
    SUM(Sales[Revenue]),
    SUM(SalesRevenueSummary[RevenueAllRegion])
)

หมายเหตุ

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

เมื่อต้องการหลีกเลี่ยงการใช้ RLS

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

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

มีข้อดีหลายอย่างที่เกี่ยวข้องกับการหลีกเลี่ยงการใช้ RLS:

• ปรับปรุงประสิทธิภาพคิวรี: ซึ่งสามารถส่งผลให้ประสิทธิภาพดีขึ้นเนื่องจากตัวกรองน้อยลง
• แบบจําลองที่เล็กลง: ในขณะที่ให้ผลในแบบจําลองที่มากขึ้น แต่มีขนาดเล็กลง แบบจําลองที่เล็กลงสามารถปรับปรุงการตอบสนองการรีเฟรชของคิวรีและข้อมูลโดยเฉพาะอย่างยิ่งหากความจุในการโฮสต์นั้นมีแรงกดดันต่อทรัพยากร นอกจากนี้ยังง่ายต่อการรักษาขนาดของแบบจําลองให้ต่ํากว่าขีดจํากัดขนาดที่กําหนดโดยความจุของคุณ สุดท้ายแล้ว มันง่ายกว่าที่จะสร้างสมดุลของปริมาณงานในความจุที่แตกต่างกัน เนื่องจากคุณสามารถสร้างพื้นที่ทํางาน—หรือย้ายพื้นที่ทํางานไปยัง—ความจุที่แตกต่างกัน
• คุณลักษณะเพิ่มเติม: ฟีเจอร์ของ Power BI ที่ไม่ทํางานกับ RLS เช่น เผยแพร่ไปยังเว็บ สามารถใช้ได้

อย่างไรก็ตามก็มีข้อเสียที่เกี่ยวข้องกับการหลีกเลี่ยงการใช้ RLS:

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

แก้ไขปัญหา RLS

หาก RLS ให้ผลลัพธ์ที่ไม่คาดคิดให้ตรวจสอบปัญหาต่อไปนี้:

• มีความสัมพันธ์ที่ไม่ถูกต้องระหว่างตารางแบบจําลองในแง่ของการแมปคอลัมน์และทิศทางตัวกรอง โปรดทราบว่าตัวกรอง RLS จะเผยแพร่ผ่านความสัมพันธ์ที่ใช้งานอยู่เท่านั้น
• คุณสมบัติ ความสัมพันธ์ ใช้ตัวกรองความปลอดภัยทั้งสองทิศทาง ไม่ถูกต้อง สําหรับข้อมูลเพิ่มเติม โปรดดู คําแนะนําความสัมพันธ์แบบสองทิศทาง
• ตารางไม่มีข้อมูล
• มีการโหลดค่าที่ไม่ถูกต้องลงในตาราง
• ผู้ใช้ถูกแมปกับหลายบทบาท
• แบบจําลองมีตารางการรวมและกฎ RLS ไม่กรองการรวมและรายละเอียดอย่างสม่ําเสมอ สําหรับข้อมูลเพิ่มเติม ดู ใช้การรวมใน Power BI Desktop (RLS สําหรับการรวม)

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

เคล็ดลับ

สําหรับวัตถุประสงค์ในการทดสอบ ให้เพิ่มหน่วยวัดที่ส่งกลับฟังก์ชัน DAX ของ USERNAME คุณอาจตั้งชื่อว่า "ใครฉัน" จากนั้นเพิ่มหน่วยวัดไปยังการ์ดวิชวลในรายงานและเผยแพร่ไปยัง Power BI

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

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

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

สําหรับข้อมูลเพิ่มเติมที่เกี่ยวข้องกับบทความนี้ โปรดดูทรัพยากรต่อไปนี้:

• การรักษาความปลอดภัยระดับแถว (RLS) ด้วย Power BI
• จํากัดการเข้าถึงข้อมูลด้วยการรักษาความปลอดภัยระดับแถว (RLS) สําหรับ Power BI Desktop
• ความสัมพันธ์ของแบบจําลองใน Power BI Desktop
• การวางแผนการใช้งาน Power BI: การวางแผนความปลอดภัยของผู้บริโภครายงาน
• คำถาม ลองถามชุมชน Power BI
• คำ แนะ นำ สนับสนุนแนวคิดในการปรับปรุง Power BI