หมายเหตุ
การเข้าถึงหน้านี้ต้องได้รับการอนุญาต คุณสามารถลอง ลงชื่อเข้าใช้หรือเปลี่ยนไดเรกทอรีได้
การเข้าถึงหน้านี้ต้องได้รับการอนุญาต คุณสามารถลองเปลี่ยนไดเรกทอรีได้
การรักษาความปลอดภัยของ Direct Lake ช่วยให้มั่นใจได้ว่าเฉพาะผู้ใช้ที่ได้รับอนุญาตเท่านั้นที่สามารถสืบค้นตารางเดลต้าใน OneLake ได้ คุณสามารถจัดการสิทธิ์การเข้าถึงข้อมูลผ่านบทบาทพื้นที่ทํางาน ผู้สนับสนุนพื้นที่ทํางาน สมาชิก และผู้ดูแลระบบสามารถอ่านข้อมูลใน OneLake ได้ คุณยังสามารถให้สิทธิ์การเข้าถึงข้อมูลใน OneLake ผ่านสิทธิ์ระดับรายการและการคํานวณ ตัวเลือกที่สามคือการใช้ประโยชน์จากการรักษาความปลอดภัยของ OneLake เพื่อบังคับใช้การรักษาความปลอดภัยตามบทบาทแบบละเอียดในเอ็นจิ้นการประมวลผล Fabric ทั้งหมด บทความนี้อธิบายวิธีการจัดแนวแบบจําลองสิทธิ์ เลือกการลงชื่อเข้าระบบครั้งเดียว (SSO) หรือข้อมูลประจําตัวแบบคงที่ และใช้ประโยชน์จากการรักษาความปลอดภัยระดับวัตถุ (OLS) และการรักษาความปลอดภัยระดับแถว (RLS) เรียนรู้เพิ่มเติมในภาพรวมความปลอดภัยของ OneLake
แนวคิดหลักและคําศัพท์
บทความนี้ถือว่าคุณคุ้นเคยกับแนวคิดเหล่านี้:
- Direct Lake ใช้นิพจน์ M ที่ใช้ร่วมกันในเมตาดาต้าของแบบจําลองความหมายเพื่ออ้างอิงแหล่งข้อมูลผ่านฟังก์ชันการเข้าถึงข้อมูล Power Query: AzureStorage.DataLake for Direct Lake บน OneLake และ Sql.Database for Direct Lake บนจุดสิ้นสุด SQL อย่างไรก็ตาม Direct Lake ไม่ได้ใช้ฟังก์ชันเหล่านี้เพื่ออ่านตารางเดลต้าต้นทาง มันอ่านตารางเดลต้าโดยตรงผ่าน OneLake API
- เพื่อให้แน่ใจว่าเฉพาะผู้ใช้ที่ได้รับอนุญาตเท่านั้นที่สืบค้นข้อมูล Direct Lake จะตรวจสอบสิทธิ์การเข้าถึงข้อมูลของข้อมูลประจําตัวที่มีผลบังคับใช้ ข้อมูลประจําตัวที่มีผลบังคับใช้ขึ้นอยู่กับการกําหนดค่าการเชื่อมต่อข้อมูล ตามค่าเริ่มต้น Direct Lake ใช้ SSO (Microsoft Entra ID) และใช้ข้อมูลประจําตัวของผู้ใช้ปัจจุบันที่คิวรีแบบจําลองความหมาย คุณยังสามารถผูกโมเดล Direct Lake กับการเชื่อมต่อระบบคลาวด์ที่ชัดเจนเพื่อให้ข้อมูลประจําตัวคงที่
- หากคุณให้สิทธิ์การเข้าถึงข้อมูลผ่านบทบาทพื้นที่ทํางาน เฉพาะสมาชิกของบทบาทผู้สนับสนุน (หรือสูงกว่า) เท่านั้นที่สามารถอ่านข้อมูลใน OneLake ได้ อย่างไรก็ตาม ผู้ชมพื้นที่ทํางานไม่มีสิทธิ์ ในการอ่าน ใน OneLake ผู้ชมและผู้ใช้ที่ไม่ใช่สมาชิกของบทบาทพื้นที่ทํางานสามารถรับสิทธิ์ การอ่าน ผ่านการรวมกันของสิทธิ์รายการ สิทธิ์การคํานวณ หรือบทบาทความปลอดภัย OneLake
- การรักษาความปลอดภัยของ OneLake ช่วยให้สมาชิกของบทบาทผู้ดูแลระบบพื้นที่ทํางานและสมาชิกพื้นที่ทํางานกําหนดการรักษาความปลอดภัยตามบทบาทแบบละเอียดสําหรับผู้ใช้ในบทบาท ผู้ชม ระบุตารางที่ผู้ชมหรือผู้ใช้ที่มีสิทธิ์ อ่าน อย่างชัดเจนสามารถเข้าถึงและยกเว้นแถวหรือคอลัมน์ที่ระบุได้ เมื่อต้องการเรียนรู้เพิ่มเติมเกี่ยวกับบทบาทความปลอดภัยของ OneLake โปรดดู ความปลอดภัยของตารางใน OneLake, การรักษาความปลอดภัยระดับคอลัมน์ใน OneLake และ RLS ใน OneLake
การกําหนดค่าการเชื่อมต่อ
กําหนดค่าการเชื่อมต่อข้อมูลสําหรับแบบจําลอง Direct Lake ในลักษณะเดียวกับชนิดแบบจําลองความหมายอื่นๆ ดู เชื่อมต่อกับแหล่งข้อมูลระบบคลาวด์ในบริการของ Power BI สําหรับรายละเอียด
การกําหนดค่า SSO (Microsoft Entra ID) เริ่มต้นมักจะใช้งานได้ ดังนั้นคุณจึงไม่จําเป็นต้องผูกแบบจําลองความหมายกับการเชื่อมต่อข้อมูลที่ชัดเจน วิธีการนี้ช่วยลดความซับซ้อนของการกําหนดค่าและลดค่าใช้จ่ายในการจัดการ
ด้วย SSO (Microsoft Entra ID) Direct Lake จะตรวจสอบว่าผู้ใช้ปัจจุบันที่สอบถามแบบจําลองความหมายมีสิทธิ์ อ่าน ข้อมูล เฉพาะผู้ใช้ที่มีสิทธิ์ อ่าน เท่านั้นที่สามารถสืบค้นข้อมูลได้ ภาพหน้าจอต่อไปนี้แสดงแบบจําลอง Direct Lake โดยใช้การกําหนดค่า SSO เริ่มต้น
เมื่อคุณใช้การเชื่อมต่อข้อมูลที่ชัดเจนด้วยข้อมูลประจําตัวคงที่แทน SSO Direct Lake ไม่ต้องการให้ผู้ใช้ทุกคนมีสิทธิ์ ในการอ่าน ข้อมูลเบื้องต้น หาก Microsoft Entra SSO ยังคงปิดใช้งานในการเชื่อมต่อข้อมูล สิทธิ์ของข้อมูลประจําตัวคงที่จะกําหนดข้อมูลที่ Direct Lake สามารถเข้าถึงได้
Note
คุณกําหนดค่าการเชื่อมต่อข้อมูลให้ใช้ทั้ง SSO และข้อมูลประจําตัวแบบคงที่ได้ Direct Lake ตรวจสอบสิทธิ์ของผู้ใช้ปัจจุบัน ณ เวลาคิวรี และใช้ข้อมูลประจําตัวคงที่สําหรับการจัดเฟรมและการแปลงรหัสในเวลารีเฟรช หากต้องการใช้ข้อมูลประจําตัวแบบคงที่สําหรับทั้งการสืบค้นและการรีเฟรช ให้ตรวจสอบว่า SSO ถูกปิดใช้งานในการกําหนดค่าการเชื่อมต่อข้อมูล
เคล็ดลับ
ใช้ SSO สําหรับสถานการณ์แบบอินเทอร์แอกทีฟที่จําเป็นต้องมีการให้สิทธิ์ต่อผู้ใช้ ใช้การเชื่อมต่อระบบคลาวด์ข้อมูลประจําตัวคงที่สําหรับสถานการณ์ผู้บริโภคแบบฝังตัวหรือแบบอ่านอย่างเดียว ซึ่งการเข้าถึงระดับแหล่งที่มาถูกกําหนดขอบเขตไว้ที่บัญชีบริการเดียว ใช้หลักการที่มีสิทธิ์น้อยที่สุดทั้งในระดับต้นทางและพื้นที่ทํางาน และทดสอบและตรวจสอบลักษณะการทํางานสําหรับโหมดการรับรองความถูกต้องทั้งสองโหมดก่อนการปรับใช้การผลิต
ข้อกําหนดในการรับรองความถูกต้อง
โมเดล Direct Lake ใช้การรับรองความถูกต้องของ Microsoft Entra ID ในการกําหนดค่าการเชื่อมต่อข้อมูล ให้เลือก OAuth 2.0, Service Principal หรือ Workspace Identity เป็นวิธีการรับรองความถูกต้อง วิธีการอื่นๆ เช่น คีย์หรือการรับรองความถูกต้อง SAS อาจปรากฏใน UI การกําหนดค่า แต่ไม่ได้รับการสนับสนุนสําหรับแบบจําลอง Direct Lake
ข้อกําหนดสิทธิ์
ข้อกําหนดสิทธิ์จะแตกต่างกันระหว่าง Direct Lake บนจุดสิ้นสุด SQL และ Direct Lake บน OneLake ความแตกต่างนี้เกิดขึ้นเพราะ Direct Lake บน SQL endpoints อาศัย SQL Analytics Endpoint ของแหล่งข้อมูลเป้าหมาย ในขณะที่ Direct Lake บน OneLake ใช้ OneLake API สําหรับการตรวจสอบสิทธิ์
Direct Lake บนจุดสิ้นสุด SQL
Direct Lake บนปลายทาง SQL จะตรวจสอบสิทธิ์ผ่านปลายทางวิเคราะห์ SQL เพื่อดูว่าตัวตนที่แท้จริงที่พยายามเข้าถึงข้อมูลมีสิทธิ์ถูกต้องหรือไม่ ตัวตนที่แท้จริงไม่จําเป็นต้องได้รับอนุญาตเพื่ออ่านตาราง Delta โดยตรงใน OneLake มันต้องการแค่สิทธิ์อ่านรายการ Fabric เช่น บ้านริมทะเลสาบ และสิทธิ์ SELECT บนตารางผ่าน SQL analytics endpoint Fabric ให้สิทธิ์โมเดลเชิงความหมายในการอ่านตาราง Delta และไฟล์ Parquet ที่เกี่ยวข้องเพื่อโหลดข้อมูลคอลัมน์เข้าสู่หน่วยความจํา โมเดลเชิงความหมายสามารถอ่านจุดสิ้นสุดการวิเคราะห์ SQL เป็นประจําเพื่อตรวจสอบว่าผู้ใช้ที่สอบถาม (หรือตัวตนคงที่) สามารถเข้าถึงข้อมูลใดได้บ้าง
Direct Lake บน OneLake
Direct Lake บน OneLake ไม่ได้ใช้ปลายพอยต์ SQL analytics ในการตรวจสอบสิทธิ์ มันใช้ระบบรักษาความปลอดภัย OneLake เมื่อเปิดใช้งานความปลอดภัยของ OneLake, Direct Lake บน OneLake จะใช้ผู้ใช้ปัจจุบัน (หรือตัวตนคงที่) เพื่อกําหนดบทบาทความปลอดภัยของ OneLake และบังคับใช้ OLS และ RLS กับไอเท็ม Fabric เป้าหมาย หากความปลอดภัยของ OneLake ไม่ได้เปิดใช้งาน Direct Lake บน OneLake จําเป็นต้องมีตัวตนที่แท้จริงเพื่อมีสิทธิ์ Read และ ReadAll บนรายการ Fabric เป้าหมายเพื่อเข้าถึงตาราง Delta ใน OneLake สําหรับข้อมูลเพิ่มเติมเกี่ยวกับสิทธิ์ Read และ ReadAll ดูที่ แชร์รายการและตั้งค่าสิทธิ์ระดับรายการ
Note
ผู้สนับสนุน (หรือสูงกว่า) มีสิทธิ์ Read และ ReadAll ใน OneLake ผู้ชมและผู้ใช้ที่ไม่ได้เป็นสมาชิกของบทบาทพื้นที่ทํางานต้องได้รับสิทธิ์ Read และ ReadAll หรือถูกเพิ่มเข้าไปในกลุ่มความปลอดภัยของ OneLake สําหรับข้อมูลเพิ่มเติมเกี่ยวกับการจัดการกลุ่มความปลอดภัย OneLake โปรดดู แบบจําลองการควบคุมการเข้าถึงข้อมูล OneLake
ผู้ใช้ Direct Lake
สถานการณ์ต่อไปนี้แสดงรายการข้อกําหนดสิทธิ์ขั้นต่ํา
| สถานการณ์สมมติ | Direct Lake บนจุดสิ้นสุด SQL | Direct Lake บน OneLake | Comments |
|---|---|---|---|
| ผู้ใช้สามารถดูรายงาน | - ให้สิทธิ์ การอ่าน สําหรับรายงานและสิทธิ์ การอ่าน สําหรับแบบจําลองความหมาย - หาก Direct Lake ใช้ SSO ให้สิทธิ์ผู้ใช้อย่างน้อย Read สําหรับรายการ Fabric เป้าหมาย และสิทธิ์ SELECT สําหรับตาราง |
- ให้สิทธิ์ การอ่าน สําหรับรายงานและสิทธิ์ การอ่าน สําหรับแบบจําลองความหมาย - หาก Direct Lake ใช้ SSO ให้สิทธิ์ผู้ใช้อย่างน้อย Read สําหรับรายการ Fabric เป้าหมาย และเพิ่มพวกเขาในบทบาทความปลอดภัยของ OneLake หรือให้สิทธิ์ ReadAll |
รายงานไม่จําเป็นต้องอยู่ในพื้นที่ทํางานเดียวกันเป็นแบบจําลองความหมาย สําหรับข้อมูลเพิ่มเติม ดูกลยุทธ์สําหรับผู้ใช้แบบอ่านอย่างเดียว |
| ผู้ใช้สามารถสร้างรายงาน | - ให้สิทธิ์ ในการสร้าง สําหรับโมเดลความหมาย - หาก Direct Lake ใช้ SSO ให้สิทธิ์ผู้ใช้อย่างน้อย Read สําหรับรายการ Fabric เป้าหมาย และสิทธิ์ SELECT สําหรับตาราง |
- ให้สิทธิ์ ในการสร้าง สําหรับโมเดลความหมาย - หาก Direct Lake ใช้ SSO ให้สิทธิ์ผู้ใช้อย่างน้อย Read สําหรับรายการ Fabric เป้าหมาย และเพิ่มพวกเขาในบทบาทความปลอดภัยของ OneLake หรือให้สิทธิ์ ReadAll |
ผู้ใช้สามารถสร้างรายงานบนตารางและคอลัมน์ที่พวกเขามีสิทธิ์เข้าถึงเท่านั้น เงื่อนไขนี้อาจเป็นส่วนย่อยของชุดตารางและคอลัมน์ทั้งหมดในโมเดล สําหรับข้อมูลเพิ่มเติม ดูกลยุทธ์สําหรับผู้สร้างเนื้อหา |
| ผู้ใช้สามารถสืบค้นแบบจําลองความหมายได้ แต่ถูกปฏิเสธไม่ให้สืบค้นตําแหน่งข้อมูลการวิเคราะห์เลคเฮาส์หรือ SQL | - ผูกโมเดล Direct Lake กับการเชื่อมต่อระบบคลาวด์ที่มีข้อมูลประจําตัวคงที่และปิดใช้งาน SSO ทิ้งไว้ - ให้สิทธิ์ Read อย่างน้อยสําหรับไอเท็ม Fabric เป้าหมาย และสิทธิ์ SELECT สําหรับตาราง - อย่าให้สิทธิ์ผู้ใช้สําหรับไอเท็ม Fabric เป้าหมาย |
- ผูกโมเดล Direct Lake กับการเชื่อมต่อระบบคลาวด์ที่มีข้อมูลประจําตัวคงที่และปิดใช้งาน SSO ทิ้งไว้ - ให้สิทธิ์ Read อย่างน้อยแก่ตัวตนคงที่สําหรับรายการ Fabric เป้าหมาย และเพิ่มเข้าไปในบทบาทความปลอดภัยของ OneLake หรือให้สิทธิ์ ReadAll - อย่าให้สิทธิ์ผู้ใช้สําหรับไอเท็ม Fabric เป้าหมาย |
เหมาะสําหรับการเชื่อมต่อระบบคลาวด์ใช้ข้อมูลประจําตัวคงที่เท่านั้น |
| ผู้ใช้สามารถสืบค้นแบบจําลองความหมายและจุดสิ้นสุดการวิเคราะห์ SQL ได้ แต่ถูกปฏิเสธไม่ให้สืบค้นเลคเฮาส์ | - ให้สิทธิ์ Readและ ReadData สําหรับรายการ Fabric เป้าหมาย | N/A | สําคัญ: คําสั่งที่ส่งไปยังปลายทางวิเคราะห์ SQL จะข้ามสิทธิ์การเข้าถึงข้อมูลที่โมเดลความหมายบังคับใช้ |
| จัดการแบบจําลองความหมาย รวมถึงการตั้งค่าการรีเฟรช | - ต้องมีความเป็นเจ้าของโมเดลความหมาย | - ต้องมีความเป็นเจ้าของโมเดลความหมาย | สําหรับข้อมูลเพิ่มเติม โปรดดู ความเป็นเจ้าของแบบจําลองความหมาย |
สําคัญ
ทดสอบสิทธิ์เสมอก่อนที่จะเผยแพร่แบบจําลองความหมายและรายงานไปยังการผลิต
สําหรับข้อมูลเพิ่มเติม ให้ดู สิทธิ์แบบจําลองเชิงความหมาย
เจ้าของทะเลสาบโดยตรง
นอกจากอัตลักษณ์ที่มีประสิทธิผล (ผู้ใช้ปัจจุบันหรืออัตลักษณ์คงที่) Direct Lake ยังต้องการให้เจ้าของโมเดลเชิงความหมายมีสิทธิ์ อ่าน ตารางต้นทาง เพื่อให้ Direct Lake สามารถกําหนดกรอบโมเดลเชิงความหมายเป็นส่วนหนึ่งของการรีเฟรชข้อมูล ไม่ว่าใครจะรีเฟรชโมเดล Direct Lake Direct Lake จะตรวจสอบสิทธิ์ของเจ้าของเพื่อให้แน่ใจว่าโมเดลได้รับอนุญาตให้เข้าถึงข้อมูล ข้อกําหนดสิทธิ์การเข้าถึงข้อมูลของเจ้าของจะเหมือนกับสําหรับผู้ใช้ที่สอบถามแบบจําลอง
หากเจ้าของโมเดลความหมายไม่มีสิทธิ์การเข้าถึงข้อมูลที่จําเป็น Direct Lake จะทําให้เกิดข้อผิดพลาดต่อไปนี้ระหว่างการวางเฟรม: We cannot refresh this semantic model because one or multiple source tables either do not exist or access was denied. Please contact a data source admin to verify that the tables exist and ensure that the owner of this semantic model does have read access to these tables. Some restricted tables including fully restricted and partially restricted (indicating column constraints): '\<list of tables\>'.
ทางลัดไปยังตารางต้นทาง
ทางลัดคือวัตถุ OneLake ที่คุณเพิ่มเข้าไปใน Fabric lakehouse หรือไอเท็ม Fabric อื่น ๆ เพื่อชี้ไปยังสถานที่จัดเก็บภายในหรือภายนอก ในโมเดล Direct Lake ตาราง Delta ที่เพิ่มผ่านทางลัดจะปรากฏเป็นเนทีฟในรายการ Fabric ที่เชื่อมต่อ เพราะทางลัดจะโปร่งใสเมื่อคุณเข้าถึงข้อมูลผ่าน OneLake API
เมื่อคุณเข้าถึงทางลัดผ่าน Direct Lake ผ่านจุดสิ้นสุด SQL Direct Lake จะตรวจสอบก่อนว่าข้อมูลประจําตัวที่มีประสิทธิภาพ (ผู้ใช้ปัจจุบันหรือข้อมูลประจําตัวคงที่) สามารถเข้าถึงตารางในแหล่งข้อมูลของแบบจําลองความหมายได้ สําหรับทางลัดภายใน หลังจากผ่านการตรวจสอบนั้น Direct Lake จะใช้ตัวตนของเจ้าของแหล่งข้อมูลเพื่ออ่านตาราง Delta ผ่านทางลัดที่รายการ Fabric ของตาราง เจ้าของแหล่งข้อมูลต้องมีสิทธิ์การเข้าถึงในตําแหน่งที่ตั้ง OneLake เป้าหมาย สําหรับทางลัดภายนอก เจ้าของแหล่งข้อมูลยังต้องมีสิทธิ์ ใช้บนการเชื่อมต่อระบบคลาวด์กับระบบภายนอกที่โฮสต์ตารางเดลต้า สําหรับข้อมูลเพิ่มเติม ให้ดู ทางลัด OneLake
Direct Lake ผ่าน OneLake มีข้อกําหนดสิทธิ์ที่แตกต่างกันเนื่องจากไม่มีส่วนเกี่ยวข้องกับปลายทาง SQL Analytics เมื่อผู้ใช้เข้าถึงข้อมูลผ่านทางลัดภายในไปยังตําแหน่งที่ตั้ง OneLake อื่น ข้อมูลประจําตัวที่มีผลบังคับใช้ (ผู้ใช้ปัจจุบันหรือข้อมูลประจําตัวคงที่) จะต้องมีสิทธิ์ในตําแหน่งเป้าหมาย ข้อมูลประจําตัวที่มีผลบังคับใช้ต้องเป็นผู้สนับสนุน (หรือสูงกว่า) มีสิทธิ์ Read และ ReadAll หรืออยู่ใน Security role ของ OneLake ที่ให้สิทธิ์การเข้าถึงการอ่าน
การรักษาความปลอดภัยระดับวัตถุ (OLS) และการรักษาความปลอดภัยระดับแถว (RLS)
ทั้งรุ่น OneLake security และ Direct Lake รองรับ OLS และ RLS OLS ช่วยให้เจ้าของรายการและผู้ดูแลระบบสามารถรักษาความปลอดภัยตารางหรือคอลัมน์เฉพาะได้ สามารถใช้ RLS เพื่อจํากัดการเข้าถึงข้อมูลที่ระดับแถวตามตัวกรอง คุณสามารถกําหนด OLS และ RLS ในความปลอดภัยของ OneLake, ในโมเดล Direct Lake หรือทั้งสองตําแหน่ง
สําคัญ
Direct Lake ไม่รองรับ OLS/RLS ปลายทางการวิเคราะห์ SQL ในหน่วยความจํา ตําแหน่งข้อมูล Direct Lake over SQL จะจัดการกับข้อจํากัดเหล่านี้แตกต่างกันไปตามประเภท ถ้าแบบสอบถามสัมผัสกับตารางหรือคอลัมน์ที่ถูกจํากัดโดย OLS ปลายทางการวิเคราะห์ SQL หรือการรักษาความปลอดภัยระดับคอลัมน์ (CLS) แบบสอบถามจะส่งกลับข้อผิดพลาด ถ้าคิวรีอ้างอิงตารางที่บังคับใช้ RLS หรือมุมมองที่จุดสิ้นสุดการวิเคราะห์ SQL คิวรีจะกลับไปที่โหมด DirectQuery ถ้า DirectQuery สํารองถูกปิดใช้งาน คิวรีที่ขึ้นอยู่กับ RLS หรือมุมมองผ่านจุดสิ้นสุด SQL จะล้มเหลว ทะเลสาบโดยตรงเหนือ OneLake หลีกเลี่ยงข้อจํากัดเหล่านี้ โปรดดูรายละเอียดที่หัวข้อวิธีประเมินคิวรีใน Direct Lake บน SQL
Direct Lake บน OneLake OLS/RLS พร้อม OneLake security OLS/RLS
Direct Lake บน OneLake ประเมินการเข้าถึงวัตถุที่ปลอดภัยของ OLS/RLS โดยแก้ไขบทบาทความปลอดภัยของ OneLake ของตัวตนที่แท้จริงและใช้กฎ OLS/RLS ที่กําหนดไว้ บทบาทความปลอดภัยของ OneLake จะถูกจัดการเหมือนกับบทบาท Direct Lake หากอัตลักษณ์ที่มีผลเป็นของหลายบทบาทใน OneLake security และ Direct Lake Direct Lake จะรวมบทบาทความปลอดภัยของ OneLake ก่อน จากนั้นจึงตัดผลลัพธ์กับบทบาท Direct Lake
ตารางนี้แสดงสถานการณ์แก้ไขปัญหาทั่วไปที่เกิดจากกฎความปลอดภัยของ OneLake และ Direct Lake ที่ขัดแย้งกัน
| สถานการณ์สมมติ | Comments |
|---|---|
| ไม่มีแถวที่ส่งคืนเนื่องจากการกรอง RLS | หากข้อมูลประจําตัวที่มีผลบังคับใช้ไม่มีสิทธิ์การเข้าถึงระดับแถว การสืบค้นสามารถส่งคืนผลลัพธ์ที่ว่างเปล่าได้ ลักษณะการทํางานนี้คาดว่าจะเกิดขึ้นเมื่อตัวกรอง RLS ไม่รวมแถวทั้งหมดสําหรับผู้ใช้ปัจจุบัน |
| ไม่พบตาราง ไม่พบคอลัมน์ แก้ไขชื่อไม่สําเร็จ ไม่ใช่ชื่อตาราง ตัวแปร หรือฟังก์ชันที่ถูกต้อง |
ข้อผิดพลาดเหล่านี้มักเกิดขึ้นเมื่อสิทธิ์ของวัตถุหายไปหลังจากใช้บทบาทความปลอดภัยของ OneLake |
ความแตกต่างของขอบเขต OLS/RLS
การบังคับใช้ OLS และ RLS ในความปลอดภัยของ OneLake ใช้กฎเกณฑ์ในทุกเอนจินประมวลผลและรับประกันการควบคุมการเข้าถึงที่เป็นหนึ่งเดียวสําหรับผู้ใช้ นั่นหมายความว่าไม่ว่าจะเป็นเอนจินประมวลผลใด — เช่น บ้านทะเลสาบ คลังสินค้า โมเดลเชิงความหมาย หรือรายการอื่น ๆ — กฎความปลอดภัยของ OneLake จะควบคุมการเข้าถึงข้อมูลของผู้ใช้ ในทางตรงกันข้าม OLS/RLS ที่กําหนดไว้ในแบบจําลองความหมายของ Direct Lake จะใช้ภายในขอบเขตของแบบจําลองนั้นเท่านั้น กลไกการคํานวณอื่นๆ ไม่ได้ใช้กฎความปลอดภัย Direct Lake เหล่านี้ ซึ่งสามารถสร้างผลลัพธ์ที่แตกต่างกันเมื่อผู้ใช้เข้าถึงข้อมูลผ่านเส้นทางอื่น
สําคัญ
เมื่อคุณใช้ทั้ง OneLake security OLS/RLS และ Direct Lake OLS/RLS ผู้ใช้ที่มีสิทธิ์เข้าถึง OneLake ก็ยังสามารถดึงและทํางานกับข้อมูลได้ แม้ว่ากฎโมเดล Direct Lake จะจํากัดข้อมูลมากขึ้นก็ตาม เพราะกฎระดับโมเดลจะไม่ขยายเกินกว่าโมเดล ใช้ความปลอดภัยของ OneLake เพื่อการควบคุมการเข้าถึงอย่างครอบคลุมในทุกเอนจินประมวลผล
OneLake OLS และข้อมูลเมตาของโมเดลความหมาย
ข้อมูลเมตาของแบบจําลองความหมายประกอบด้วยคําจํากัดความของตาราง คอลัมน์ ความสัมพันธ์ และองค์ประกอบ Schema อื่นๆ ผู้ใช้ที่มีสิทธิ์ ในการสร้าง หรือสูงกว่าสามารถดูข้อมูลเมตาของโมเดลผ่าน XML for Analysis (XMLA) และ REST API สําหรับข้อมูลเพิ่มเติม ให้ดู สิทธิ์แบบจําลองเชิงความหมาย
เพื่อปกป้องชื่อตารางและคอลัมน์ที่ละเอียดอ่อนใน OneLake ด้วย OneLake OLS โปรดจําไว้ว่าความปลอดภัยของ OneLake จะใช้กับสมาชิกในบทบาท Viewer ของพื้นที่ทํางานเท่านั้น OneLake OLS ไม่ป้องกันสมาชิกของบทบาท Contributor (หรือสูงกว่า) ในพื้นที่ทํางานจากการค้นหาตารางหรือคอลัมน์ที่ปลอดภัย เพราะพวกเขามีสิทธิ์เขียนข้อมูลสําหรับรายการพื้นที่ทํางานทั้งหมดอยู่แล้ว สมาชิกของบทบาท ผู้ชม ที่มีสิทธิ์ ในการสร้าง หรือสูงกว่าในแบบจําลอง Direct Lake สามารถค้นหาข้อมูล Schema ที่ละเอียดอ่อนผ่านข้อมูลเมตาของโมเดลความหมาย ผู้ชมที่มีสิทธิพิเศษสูงกว่าเหล่านี้ยังไม่มีการเข้าถึงข้อมูล แต่จะเห็นว่ามีตารางและคอลัมน์ที่ปลอดภัยอยู่
โมเดล Direct Lake อาจมีอยู่ในพื้นที่ทํางานเดียวกับรายการต้นทาง หรือในพื้นที่ทํางานแยกต่างหาก ให้สิทธิ์ผู้ชม ในการสร้างพื้นที่ทํางาน เดียวกัน (หรือสูงกว่า) เข้าถึงโมเดล Direct Lake ผ่านสิทธิ์ของรายการ ในพื้นที่ทํางานแยกต่างหาก ผู้ใช้อาจเป็นผู้สนับสนุน (หรือสูงกว่า) หรือมีสิทธิ์สร้าง (หรือสูงกว่า) เพื่อเข้าถึงข้อมูลเมตาของแบบจําลอง
การรวม OneLake OLS และ Git
การรวม Git ช่วยให้นักพัฒนาสามารถรวมกระบวนการการจัดการวงจรชีวิตของแอปพลิเคชัน (ALM) เข้ากับแพลตฟอร์ม Fabric ที่เก็บข้อมูล Git จะรักษาโครงสร้างพื้นที่ทํางาน รวมถึงรายการที่รองรับทั้งหมด นักพัฒนาสามารถมองเห็นข้อมูลเมตาของรายการทั้งหมดในที่เก็บ Git ได้อย่างเต็มที่ เมตาดาต้าแบบจําลอง Direct Lake ช่วยให้พวกเขาเห็นว่ามีตารางหรือคอลัมน์ที่ปลอดภัยอยู่ แม้ว่าพวกเขาจะไม่สามารถเข้าถึงแหล่งข้อมูลเป้าหมายในพื้นที่ทํางานอื่นก็ตาม สําหรับข้อมูลเพิ่มเติม ดู การรวม Microsoft Fabric Git คืออะไร
วิธีการประเมินคิวรีใน Direct Lake บน SQL
เหตุผลในการพัฒนาแบบจําลองความหมาย Direct Lake คือการคิวรีที่มีประสิทธิภาพสูงผ่านข้อมูลจํานวนมากใน OneLake ดังนั้นคุณควรพยายามออกแบบโซลูชันที่เพิ่มโอกาสในการคิวรีในหน่วยความจํา
ขั้นตอนต่อไปนี้จะประเมินวิธีการประเมินคิวรี Direct Lake on SQL (และล้มเหลวหรือไม่) ประโยชน์ของโหมดที่เก็บข้อมูล Direct Lake สามารถทําได้เฉพาะเมื่อขั้นตอนที่ห้าสําเร็จ
- ถ้าคิวรีมีตารางหรือคอลัมน์ใด ๆ ที่ถูกจํากัดโดย OLS แบบจําลองความหมาย ผลลัพธ์ข้อผิดพลาดจะถูกส่งกลับ (วิชวลรายงานล้มเหลวในการแสดงผล)
- ถ้าคิวรีมีคอลัมน์ใด ๆ ที่ถูกจํากัดโดย CLS จุดสิ้นสุดการวิเคราะห์ SQL (หรือตารางถูกปฏิเสธ) ผลลัพธ์ข้อผิดพลาดจะถูกส่งกลับ (วิชวลรายงานล้มเหลวในการแสดงผล)
- ถ้าการเชื่อมต่อระบบคลาวด์ใช้ SSO (ค่าเริ่มต้น) CLS จะถูกกําหนดโดยระดับการเข้าถึงของผู้ใช้รายงาน
- ถ้าการเชื่อมต่อคลาวด์ใช้ข้อมูลประจําตัวแบบคงที่ CLS จะถูกกําหนดโดยระดับการเข้าถึงของข้อมูลประจําตัวแบบคงที่
- ถ้าแบบจําลองความหมายใช้ Direct Lake บนจุดสิ้นสุด SQL และคิวรีมีตารางใดๆ ในจุดสิ้นสุดการวิเคราะห์ SQL ที่บังคับใช้ RLS หรือใช้มุมมอง คิวรีจะกลับไปที่โหมด DirectQuery
- ถ้าการเชื่อมต่อระบบคลาวด์ใช้ SSO (ค่าเริ่มต้น) RLS จะถูกกําหนดโดยระดับการเข้าถึงของผู้ใช้รายงาน
- ถ้าการเชื่อมต่อคลาวด์ใช้ข้อมูลประจําตัวแบบคงที่ RLS จะถูกกําหนดโดยระดับการเข้าถึงของข้อมูลประจําตัวแบบคงที่
- ถ้าคิวรี เกิน guardrails ของความจุ คิวรีนั้นจะกลับสู่โหมด DirectQuery
- มิฉะนั้น คิวรีจะพอใจกับแคชในหน่วยความจํา ข้อมูลคอลัมน์จะถูก โหลดลงในหน่วยความจํา เมื่อจําเป็น
สําคัญ
Direct Lake บน OneLake ไม่รองรับการสํารองไปยังโหมด DirectQuery ถ้าตารางใด ๆ ในจุดสิ้นสุดการวิเคราะห์ SQL บังคับใช้ RLS หรือคิวรี เกินขอบเขตของความจุ ผลลัพธ์ข้อผิดพลาดจะถูกส่งกลับ (วิชวลรายงานไม่สามารถแสดงผลได้)
ตัวเลือกกฎการเข้าถึงข้อมูล
คุณสามารถตั้งค่ากฎการเข้าถึงข้อมูลได้ใน:
- แบบจําลองความหมาย
- ตําแหน่งข้อมูลการวิเคราะห์ SQL (Direct Lake บนตําแหน่งข้อมูล SQL เท่านั้น)
- ความปลอดภัยของ OneLake
กฎในแบบจําลองความหมาย
หากคุณต้องการบังคับใช้กฎการเข้าถึงข้อมูล ให้ทําใน OneLake Security เพื่อให้กฎเหล่านั้นครอบคลุมทุกเอนจินการประมวลผลและรับประกันการควบคุมการเข้าถึงที่เป็นหนึ่งเดียวสําหรับผู้ใช้ ใช้แบบจําลองความหมาย RLS หรือ OLS เมื่อผู้ใช้รายงานไม่ได้รับสิทธิ์ในการสอบถามเลคเฮาส์หรือคลังสินค้า และการเชื่อมต่อระบบคลาวด์ใช้ข้อมูลประจําตัวคงที่แทน SSO SSO หมายความว่าผู้ใช้ปลายทางสามารถเข้าถึงแหล่งข้อมูลได้โดยตรง และอาจข้ามกฎความปลอดภัยในแบบจําลองความหมาย
สําคัญ
สิทธิ์รายการแบบจําลองเชิงความหมายสามารถ ตั้งค่าอย่างชัดเจน ผ่านทาง แอป Power BI หรือ ได้รับโดยนัย ผ่านบทบาทพื้นที่ทํางาน
ที่น่าสังเกตคือ กฎการเข้าถึงข้อมูลของโมเดลเชิงความหมายจะไม่ถูกบังคับใช้กับผู้ใช้ที่มีสิทธิ์ เขียน บนแบบจําลองเชิงความหมาย ในทางกลับกัน กฎการเข้าถึงข้อมูลจะนําไปใช้กับผู้ใช้ที่ได้รับมอบหมายบทบาทพื้นที่ทํางานของผู้ชม อย่างไรก็ตาม ผู้ใช้ที่ได้รับมอบหมายให้เป็น บทบาท Admin, Member หรือ Contributor workspace จะมีสิทธิ์ Write บนโมเดลเชิงความหมายโดยนัย ดังนั้นกฎการเข้าถึงข้อมูลจึงไม่ถูกบังคับใช้ สําหรับข้อมูลเพิ่มเติม โปรดดู บทบาทในพื้นที่ทํางาน
กฎในหลายชั้น
คุณสามารถบังคับใช้กฎการเข้าถึงข้อมูลได้ทุกชั้น อย่างไรก็ตาม วิธีการนี้เกี่ยวข้องกับความซับซ้อนและค่าใช้จ่ายในการจัดการที่มากเกินไป ในกรณีนี้ ให้ใช้ตัวตนคงที่สําหรับการเชื่อมต่อคลาวด์แทน SSO
เปรียบเทียบตัวเลือกกฎการเข้าถึงข้อมูล
ตารางต่อไปนี้เปรียบเทียบตัวเลือกการตั้งค่าการเข้าถึงข้อมูลสําหรับ Direct Lake บนจุดสิ้นสุด SQL และ Direct Lake บน OneLake
| ใช้กฎการเข้าถึงข้อมูลกับ | Direct Lake บน SQL | Direct Lake บน OneLake | ข้อคิดเห็น |
|---|---|---|---|
| เฉพาะแบบจําลองแสดงความหมายเท่านั้น | ได้รับการสนับสนุน | ได้รับการสนับสนุน | ใช้ตัวเลือกนี้เมื่อผู้ใช้ไม่ได้รับสิทธิ์รายการในการคิวรีของเลคเฮ้าส์หรือคลังสินค้า ตั้งค่าการเชื่อมต่อระบบคลาวด์เพื่อใช้ข้อมูลประจําตัวแบบคงที่ เพิ่มประสิทธิภาพการสืบค้นสูงจากแคชในหน่วยความจํา |
| จุดสิ้นสุดการวิเคราะห์ SQL เท่านั้น | ได้รับการสนับสนุน (ย้อนกลับไปที่ DirectQuery) | ไม่มีผลบังคับใช้ | ขึ้นอยู่กับรายการข้อมูล Fabric (เช่น Lakehouse หรือ Warehouse) โดยใช้โหมดข้อมูลประจําตัวที่ได้รับมอบหมาย ใช้ตัวเลือกนี้เมื่อผู้ใช้จําเป็นต้องเข้าถึงข้อมูลจากคลังสินค้าหรือแบบจําลองความหมาย และด้วยกฎการเข้าถึงข้อมูลที่สอดคล้องกัน ตรวจสอบให้แน่ใจว่ามีการเปิดใช้งาน SSO สําหรับการเชื่อมต่อระบบคลาวด์ ประสิทธิภาพของคิวรีอาจช้าเนื่องจากการสํารองของ DirectQuery |
| ความปลอดภัยของ OneLake เท่านั้น | ไม่มีผลบังคับใช้ | ได้รับการสนับสนุน | ใช้ตัวเลือกนี้สําหรับการควบคุมการเข้าถึงแบบรวมในกลไกการคํานวณ Fabric ทั้งหมด การรักษาความปลอดภัยของ OneLake บังคับใช้ OLS และ RLS อย่างสม่ําเสมอสําหรับผู้ใช้ทุกคนที่เข้าถึงข้อมูลผ่านทุกเส้นทาง เพิ่มประสิทธิภาพการสืบค้นสูงจากแคชในหน่วยความจํา |
| หลายเลเยอร์ (แบบจําลองความหมายและปลายทาง SQL) | ได้รับการสนับสนุน | ไม่มีผลบังคับใช้ | ตัวเลือกนี้เกี่ยวข้องกับค่าใช้จ่ายในการจัดการเพิ่มเติม ตั้งค่าการเชื่อมต่อระบบคลาวด์เพื่อใช้ข้อมูลประจําตัวแบบคงที่ |
| หลายเลเยอร์ (โมเดลความหมายและความปลอดภัยของ OneLake) | ไม่มีผลบังคับใช้ | ได้รับการสนับสนุน | กฎความปลอดภัยของ OneLake จะถูกนําไปใช้ก่อน จากนั้นจึงใช้กฎแบบจําลองความหมาย พิจารณารวมกฎไว้ที่เลเยอร์เดียวเพื่อลดความซับซ้อน |
ข้อควรพิจารณาและข้อจำกัด
พิจารณาข้อจํากัดด้านความปลอดภัยของ Direct Lake เหล่านี้
Note
ความสามารถและคุณสมบัติของโมเดลความหมายของ Direct Lake และการรักษาความปลอดภัย OneLake พัฒนาอย่างรวดเร็ว กลับมาตรวจสอบการอัปเดตเป็นระยะ
- กําหนดบทบาทความปลอดภัย OneLake ให้กับผู้ดูพื้นที่ทํางานที่ให้สิทธิ์อ่านรายการ Fabric ต้นทาง หากรายการต้นทางมีทางลัดไปยังรายการ Fabric อื่น ผู้ใช้ก็ต้องมีสิทธิ์อ่านรายการ Fabric เป้าหมายของทางลัดแต่ละรายการด้วย
- ใช้ตัวตนคงที่เพื่อแยกผู้ใช้ออกจากรายการ Fabric ต้นทาง ผูกโมเดล Direct Lake กับการเชื่อมต่อระบบคลาวด์ ปิดใช้งาน SSO ในการเชื่อมต่อระบบคลาวด์เพื่อใช้ข้อมูลประจําตัวแบบคงที่สําหรับการรีเฟรชและการสืบค้น
- โมเดลเซแมนติก Direct Lake ที่พึ่งพาความปลอดภัยของ Fabric OneLake บนรายการต้นทางไม่รองรับการสํารองข้อมูล
- ความสัมพันธ์แบบสองทางจะไม่รองรับในโมเดล Direct Lake หากรายการ Fabric ต้นทางพึ่งพา OneLake security RLS
- การรักษาความปลอดภัยของ OneLake ไม่สนับสนุนข้อกําหนดแบบไดนามิกหรือการกําหนดค่าบทบาทที่ซับซ้อน เช่น การรวมบทบาท OLS และ RLS หลายบทบาทในตารางที่เกี่ยวข้อง
- รวมสิทธิ์ RLS และ OLS ด้านความปลอดภัยของ OneLake ไว้ในหนึ่งบทบาทต่อผู้ใช้แทนการกําหนดหลายบทบาท
- หากการกําหนดค่าความปลอดภัยของ OneLake เปลี่ยนแปลง เช่น เนื่องจากการเปลี่ยนแปลงทางลัดในรายการเป้าหมาย ให้รีเฟรช Direct Lake บนโมเดล OneLake ที่เข้าถึงรายการนั้น คุณต้องรีเฟรชแบบจําลองด้วยตนเองหรือโดยใช้ API การรีเฟรช
- หากเลคเฮาส์มีระบบรักษาความปลอดภัย OneLake:
- โดยค่าเริ่มต้น ตําแหน่งข้อมูลการวิเคราะห์ SQL เป็นข้อมูลประจําตัวคงที่สําหรับเจ้าของ Lakehouse ดังนั้นการรักษาความปลอดภัยของ OneLake ปลายทางการวิเคราะห์ SQL จึงเหมือนกับเจ้าของ (ไม่มีข้อจํากัด) Direct Lake บน SQL จะยังคงใช้ Direct Lake เว้นแต่จะมีการเพิ่มบทบาทการเข้าถึงแบบละเอียดของ SQL เพิ่มเติม
- ตําแหน่งข้อมูลการวิเคราะห์ SQL สามารถเปลี่ยนเป็น SSO ได้ เมื่อสิ่งนี้เกิดขึ้น Security role ของ OneLake จะถูกเพิ่มเป็นกฎการควบคุมการเข้าถึงแบบละเอียดของ SQL และผู้ใช้จะถูกบล็อกไม่ให้แก้ไขโดยตรงบนจุดสิ้นสุดการวิเคราะห์ SQL ณ จุดนี้ Direct Lake บน SQL จะถอยกลับไปที่ DirectQuery 100% ของเวลา