กิจกรรม
เข้าร่วมกับเราที่ FabCon Vegas
31 มี.ค. 23 - 2 เม.ย. 23
เหตุการณ์ที่นําโดยชุมชนของ Microsoft Fabric, Power BI, SQL และ AI 31 มีนาคมถึงวันที่ 2 เมษายน 2025
ลงทะเบียนวันนี้เบราว์เซอร์นี้ไม่ได้รับการสนับสนุนอีกต่อไป
อัปเกรดเป็น Microsoft Edge เพื่อใช้ประโยชน์จากคุณลักษณะล่าสุด เช่น การอัปเดตความปลอดภัยและการสนับสนุนด้านเทคนิค
บทความนี้มุ่งเป้าหมายไปยังคุณในฐานะผู้สร้างแบบจําลองข้อมูลที่ทํางานกับ 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 ทํางานโดยการนําตัวกรองไปใช้กับคิวรี DAX ทั้งหมดโดยอัตโนมัติ และตัวกรองเหล่านี้อาจมีผลกระทบเชิงลบต่อประสิทธิภาพการทํางานของคิวรี ดังนั้น RLS ที่มีประสิทธิภาพมาจากการออกแบบแบบจําลองที่ดี สิ่งสําคัญคือต้องปฏิบัติตามคําแนะนําการออกแบบแบบจําลองตามที่อธิบายไว้ในบทความต่อไปนี้:
โดยทั่วไป มักจะมีประสิทธิภาพมากกว่าในการบังคับใช้ตัวกรอง RLS ในตารางประเภทมิติและไม่ใช่ตารางประเภทข้อเท็จจริง และขึ้นอยู่กับความสัมพันธ์ที่ออกแบบมาอย่างดีเพื่อให้แน่ใจว่าตัวกรอง RLS เผยแพร่ไปยังตารางแบบจําลองอื่น ตัวกรอง RLS เผยแพร่ผ่านความสัมพันธ์ที่ใช้งานอยู่เท่านั้น ดังนั้น ให้หลีกเลี่ยงการใช้ฟังก์ชัน DAX ของ LOOKUPVALUE เมื่อความสัมพันธ์ของแบบจําลองสามารถทําให้เกิดผลลัพธ์เดียวกันได้
เมื่อใดก็ตามที่มีการบังคับใช้ตัวกรอง RLS ในตาราง DirectQuery และมีความสัมพันธ์กับตาราง DirectQuery อื่น ๆ ตรวจสอบให้แน่ใจว่าได้ปรับใช้ฐานข้อมูลต้นทางให้เหมาะสม ซึ่งอาจเกี่ยวข้องกับการออกแบบดัชนีที่เหมาะสมหรือใช้คอลัมน์ที่มีการคํานวณอยู่ สําหรับข้อมูลเพิ่มเติม โปรดดูคําแนะนําแบบจําลอง DirectQuery ใน Power BI Desktop
สามารถวัดผลกระทบของประสิทธิภาพการทํางานของตัวกรอง RLS ใน Power BI Desktop โดยใช้ตัววิเคราะห์ประสิทธิภาพ ก่อนอื่น ให้กําหนดระยะเวลาของคิวรีวิชวลรายงานเมื่อ RLS ไม่ได้บังคับใช้ จากนั้นใช้คําสั่ง ดูเป็น บนแท็บ ริบบอน การสร้าง แบบจําลอง เพื่อบังคับใช้ RLS และกําหนดและเปรียบเทียบระยะเวลาคิวรี
เมื่อเผยแพร่ไปยัง Power BI แล้ว คุณต้องแมปสมาชิกไปยังบทบาทแบบจําลองเชิงความหมาย เฉพาะเจ้าของแบบจําลองความหมายหรือผู้ดูแลระบบพื้นที่ทํางานเท่านั้นที่สามารถเพิ่มสมาชิกไปยังบทบาทได้ สําหรับข้อมูลเพิ่มเติม โปรดดูการรักษาความปลอดภัยระดับแถว (RLS) ด้วย Power BI (จัดการความปลอดภัยบนแบบจําลองของคุณ)
สมาชิกสามารถเป็นบัญชีผู้ใช้ กลุ่มความปลอดภัย กลุ่มการแจกจ่าย หรือกลุ่มจดหมายที่เปิดใช้งาน เมื่อใดก็ตามที่เป็นไปได้ เราขอแนะนําให้คุณแมปกลุ่มความปลอดภัยไปยังบทบาทแบบจําลองเชิงความหมาย ซึ่งเกี่ยวข้องกับการจัดการการเป็นสมาชิกกลุ่มความปลอดภัยใน Microsoft Entra ID อาจเป็นไปได้ว่าได้มอบหมายงานให้กับผู้ดูแลระบบเครือข่ายของคุณ
ทดสอบแต่ละบทบาทเพื่อให้แน่ใจว่ามีการกรองแบบจําลองได้อย่างถูกต้อง ทําได้อย่างง่ายดายโดยใช้คําสั่ง ดูเป็น บนแท็บ ริบบอน การสร้าง แบบจําลอง
เมื่อแบบจําลองมีกฎแบบไดนามิกที่ใช้ฟังก์ชัน 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 ตัวอย่างเช่น รายงานอาจจําเป็นต้องแสดงอัตราส่วนของรายได้ที่ได้รับสําหรับภูมิภาคการขายของผู้ใช้รายงานในรายได้ทั้งหมดที่ได้รับ
แม้ว่านิพจน์ DAX จะไม่สามารถแทนที่ RLS ได้ — แต่ในความเป็นจริงจะไม่สามารถกําหนดได้ว่า RLS นั้นถูกบังคับใช้หรือไม่ — คุณสามารถใช้ตารางแบบจําลองสรุปได้ ตารางแบบจําลองสรุปจะได้รับการสอบถามเพื่อดึงรายได้สําหรับ "ภูมิภาคทั้งหมด" และไม่ได้ถูกจํากัดโดยตัวกรอง RLS ใดๆ
มาดูกันว่าคุณสามารถใช้ข้อกําหนดการออกแบบนี้ได้อย่างไร ก่อนอื่น ให้พิจารณาการออกแบบแบบจําลองต่อไปนี้:
แบบจําลองประกอบด้วยสี่ตาราง:
นิพจน์ต่อไปนี้กําหนดตารางที่มีการคํานวณของ 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:
หาก RLS ให้ผลลัพธ์ที่ไม่คาดคิดให้ตรวจสอบปัญหาต่อไปนี้:
เมื่อผู้ใช้ที่ระบุไม่สามารถดูข้อมูลใด ๆ ได้ อาจเป็นเพราะ UPN ไม่ได้ถูกจัดเก็บไว้ หรือระบบป้อนข้อมูลไม่ถูกต้อง ซึ่งสามารถเกิดขึ้นทันทีเนื่องจากบัญชีผู้ใช้ของพวกเขามีการเปลี่ยนแปลงเนื่องจากผลของการเปลี่ยนชื่อ
เคล็ดลับ
สําหรับวัตถุประสงค์ในการทดสอบ ให้เพิ่มหน่วยวัดที่ส่งกลับฟังก์ชัน DAX ของ USERNAME คุณอาจตั้งชื่อว่า "ฉันเป็นใคร" จากนั้นเพิ่มหน่วยวัดไปยังการ์ดวิชวลในรายงานและเผยแพร่ไปยัง Power BI
ผู้สร้างและผู้บริโภคที่มีสิทธิ์ในการอ่านเฉพาะบนแบบจําลองความหมายเท่านั้นจะสามารถดูข้อมูลที่ได้รับอนุญาตให้ดู (ตามการแมปบทบาท RLS ของพวกเขา)
เมื่อผู้ใช้ดูรายงานในพื้นที่ทํางานหรือแอป RLS อาจหรืออาจไม่ถูกบังคับใช้ ทั้งนี้ขึ้นอยู่กับสิทธิ์แบบจําลองเชิงความหมายของพวกเขา ด้วยเหตุผลนี้ จึงเป็นสิ่งสําคัญที่ผู้บริโภคและผู้สร้างเนื้อหาจะต้องมีสิทธิ์ในการอ่านบนแบบจําลองความหมายพื้นฐานเมื่อมีการบังคับใช้ RLS เท่านั้น สําหรับรายละเอียดเกี่ยวกับกฎสิทธิ์ที่กําหนดว่าจะบังคับใช้ RLS หรือไม่ ให้ดู บทความการวางแผน ความปลอดภัยของผู้บริโภครายงาน
สําหรับข้อมูลเพิ่มเติมที่เกี่ยวข้องกับบทความนี้ โปรดดูทรัพยากรต่อไปนี้:
กิจกรรม
เข้าร่วมกับเราที่ FabCon Vegas
31 มี.ค. 23 - 2 เม.ย. 23
เหตุการณ์ที่นําโดยชุมชนของ Microsoft Fabric, Power BI, SQL และ AI 31 มีนาคมถึงวันที่ 2 เมษายน 2025
ลงทะเบียนวันนี้การฝึกอบรม
โมดูล
ใช้การรักษาความปลอดภัยระดับแถว - Training
การรักษาความปลอดภัยระดับแถว (RLS) ช่วยให้คุณสามารถสร้างรายงานฉบับเดียวหรือรายงานชุดเดียว โดยมุ่งเน้นที่ข้อมูลสำหรับผู้ใช้เฉพาะราย ในมอดูลนี้ คุณจะได้เรียนรู้วิธีการใช้งาน RLS โดยใช้เมธอดแบบคงที่หรือแบบไดนามิก และวิธีที่ Microsoft Power BI ช่วยลดความยุ่งยากในการทดสอบ RLS ใน Power BI Desktop และบริการของ Power BI
ใบรับรอง
Microsoft Certified: Power BI Data Analyst Associate - Certifications
Demonstrate methods and best practices that align with business and technical requirements for modeling, visualizing, and analyzing data with Microsoft Power BI.