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

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

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

สร้างบทบาท

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

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

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

FALSE()

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

TRUE()

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

ปรับใช้ RLS

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

• ทำความเข้าใจแบบจำลองมิติที่มีลักษณะคล้ายดาวและความสำคัญที่มีต่อ Power BI
• บทความคำแนะนำของความสัมพันธ์ทั้งหมดที่พบใน เอกสารคำแนะนำของ Power BI

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

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

วัดผลกระทบ RLS

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

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

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

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

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

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

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

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

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

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 ค่าคอลัมน์ ภูมิภาค (สำหรับผู้ใช้รายงาน) ได้กระจายไปยังตาราง ยอดขาย
	มีความสัมพันธ์แบบหนึ่งต่อกลุ่มระหว่าง วันที่ และตาราง ยอดขาย
	มีความสัมพันธ์แบบหนึ่งต่อกลุ่มระหว่าง วันที่ และตารางของ SalesRevenueSummary

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

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

หลีกเลี่ยงการใช้ RLS

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

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

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

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

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

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

แก้ไขปัญหา RLS

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

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

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

เมื่อผู้ใช้ที่เฉพาะเจาะจงสามารถดูข้อมูลทั้งหมดได้ นั่นเป็นไปได้ว่าพวกเขากำลังเข้าถึงรายงานโดยตรงในพื้นที่ทำงานและพวกเขาเป็นเจ้าของชุดข้อมูลด้วย RLS ถูกบังคับใช้เฉพาะเมื่อ:

• รายงานถูกเปิดในแอป
• รายงานถูกเปิดในพื้นที่ทำงานและผู้ใช้งานถูกแมปไปยัง บทบาทของผู้ชม

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

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

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