หมายเหตุ
การเข้าถึงหน้านี้ต้องได้รับการอนุญาต คุณสามารถลอง ลงชื่อเข้าใช้หรือเปลี่ยนไดเรกทอรีได้
การเข้าถึงหน้านี้ต้องได้รับการอนุญาต คุณสามารถลองเปลี่ยนไดเรกทอรีได้
ด้วยการรักษาความปลอดภัยของ OneLake Microsoft Fabric กําลังขยายวิธีที่องค์กรสามารถจัดการและบังคับใช้ Data access ในปริมาณงานต่างๆ เฟรมเวิร์กการรักษาความปลอดภัยใหม่นี้ช่วยให้ผู้ดูแลระบบมีความยืดหยุ่นมากขึ้นในการกําหนดค่าสิทธิ์ ผู้ดูแลระบบสามารถเลือกระหว่าง การกํากับดูแลแบบรวมศูนย์ผ่าน OneLake หรือ การควบคุมแบบ SQL แบบละเอียด ภายในตําแหน่งข้อมูลการวิเคราะห์ SQL
โหมด Access ในตําแหน่งข้อมูลการวิเคราะห์ SQL
เมื่อใช้ตําแหน่งข้อมูลการวิเคราะห์ SQL โหมด access ที่เลือกจะกําหนดวิธีการบังคับใช้ความปลอดภัยของข้อมูล Fabric รองรับโมเดล access ที่แตกต่างกันสองแบบ โดยแต่ละรุ่นให้ประโยชน์ที่แตกต่างกันขึ้นอยู่กับความต้องการด้านการดําเนินงานและการปฏิบัติตามข้อกําหนดของคุณ:
โหมดข้อมูลประจําตัวของผู้ใช้: บังคับใช้การรักษาความปลอดภัยโดยใช้บทบาทและนโยบายของ OneLake ในโหมดนี้ ตําแหน่งข้อมูลการวิเคราะห์ SQL จะส่งข้อมูลประจําตัวของผู้ใช้ที่ลงชื่อเข้าใช้ไปยัง OneLake และ read access จะถูกควบคุมโดยกฎความปลอดภัยที่กําหนดไว้ใน OneLake ทั้งหมด รองรับสิทธิ์ระดับ SQL บนตาราง เพื่อให้มั่นใจว่าการกํากับดูแลที่สอดคล้องกันในเครื่องมือต่างๆ เช่น Power BI, โน้ตบุ๊ก และเลคเฮาส์
โหมดข้อมูลประจําตัวที่ได้รับมอบหมาย: ให้การควบคุมเต็มรูปแบบผ่าน SQL ในโหมดนี้ จุดสิ้นสุดการวิเคราะห์ SQL จะเชื่อมต่อกับ OneLake โดยใช้ข้อมูลประจําตัวของ พื้นที่ทํางานหรือเจ้าของรายการ และ ความปลอดภัยจะถูกควบคุมโดยสิทธิ์ SQL ที่กําหนดไว้ภายในฐานข้อมูลเท่านั้น โมเดลนี้รองรับแนวทางการรักษาความปลอดภัยแบบดั้งเดิม รวมถึง GRANT, REVOKE, บทบาทที่กําหนดเอง, Row-Level Security และ Dynamic Data Masking
แต่ละโหมดรองรับรูปแบบการกํากับดูแลที่แตกต่างกัน การทําความเข้าใจความหมายเป็นสิ่งสําคัญสําหรับการเลือกแนวทางที่เหมาะสมในสภาพแวดล้อม Fabric ของคุณ
การเปรียบเทียบระหว่างโหมด access
ต่อไปนี้เป็นตารางเปรียบเทียบที่ชัดเจนและรัดกุมซึ่งมุ่งเน้นไปที่วิธีและตําแหน่งที่คุณตั้งค่าความปลอดภัยในโหมดข้อมูลประจําตัวของผู้ใช้เทียบกับโหมดข้อมูลประจําตัวที่ได้รับมอบหมาย โดยแบ่งตามประเภทออบเจ็กต์และนโยบาย Data access:
| เป้าหมายความปลอดภัย | โหมดการระบุตัวตนของผู้ใช้ | โหมดข้อมูลประจําตัวที่ได้รับมอบหมาย |
|---|---|---|
| ตาราง | Access ถูกควบคุมโดยบทบาทความปลอดภัยของ OneLake ไม่อนุญาตให้ใช้ SQL GRANT/REVOKE |
ควบคุมได้อย่างเต็มที่โดยใช้ SQL GRANT/REVOKE. |
| มุมมอง | ใช้ SQL GRANT/REVOKE เพื่อกําหนดสิทธิ์ | ใช้ SQL GRANT/REVOKE เพื่อกําหนดสิทธิ์ |
| กระบวนงานที่เก็บไว้ | ใช้ SQL GRANT EXECUTE เพื่อกําหนดสิทธิ์ | ใช้ SQL GRANT EXECUTE เพื่อกําหนดสิทธิ์ |
| Functions | ใช้ SQL GRANT EXECUTE เพื่อกําหนดสิทธิ์ | ใช้ SQL GRANT EXECUTE เพื่อกําหนดสิทธิ์ |
| Row-Level ความปลอดภัย (RLS) | กําหนดไว้ใน OneLake UI เป็นส่วนหนึ่งของบทบาทความปลอดภัยของ OneLake | กําหนดโดยใช้ SQL CREATE SECURITY POLICY |
| Column-Level ความปลอดภัย (CLS) | กําหนดไว้ใน OneLake UI เป็นส่วนหนึ่งของบทบาทความปลอดภัยของ OneLake | กําหนดโดยใช้ SQL GRANT SELECT กับรายการคอลัมน์ |
| การมาสก์ข้อมูลแบบไดนามิก (DDM) | ไม่รองรับในการรักษาความปลอดภัย OneLake | กําหนดโดยใช้ SQL ALTER TABLE พร้อม MASKED ตัวเลือก |
โหมดข้อมูลประจําตัวผู้ใช้ในการรักษาความปลอดภัย OneLake
ในโหมดข้อมูลประจําตัวผู้ใช้ ปลายทางการวิเคราะห์ SQL จะใช้กลไกการรับรองความถูกต้อง passthrough เพื่อบังคับใช้ access ข้อมูล เมื่อผู้ใช้เชื่อมต่อกับตําแหน่งข้อมูลการวิเคราะห์ SQL ข้อมูลประจําตัว Entra ID ของพวกเขาจะถูกส่งผ่านไปยัง OneLake ซึ่งจะทําการตรวจสอบสิทธิ์ การดําเนินการอ่านทั้งหมดกับตารางจะได้รับการประเมินโดยใช้กฎความปลอดภัยที่กําหนดไว้ใน OneLake Lakehouse ไม่ใช่โดยคําสั่ง GRANT หรือ REVOKE ระดับ SQL
โหมดนี้ช่วยให้คุณสามารถจัดการความปลอดภัยจากส่วนกลาง เพื่อให้มั่นใจว่าการบังคับใช้ที่สอดคล้องกันในประสบการณ์ Fabric ทั้งหมด รวมถึง Power BI, สมุดบันทึก, เลคเฮาส์ และปลายทางการวิเคราะห์ SQL ออกแบบมาสําหรับโมเดลการกํากับดูแลที่ควรกําหนด access เพียงครั้งเดียวใน OneLake และได้รับการเคารพโดยอัตโนมัติทุกที่
ในโหมดข้อมูลประจําตัวผู้ใช้:
Table access ถูกควบคุมโดยความปลอดภัยของ OneLake ทั้งหมด คําสั่ง SQL GRANT/REVOKE บนตารางจะถูกละเว้น
RLS (Row-Level Security), CLS (Column-Level Security) และ Object-Level Security ทั้งหมดถูกกําหนดไว้ในประสบการณ์การใช้งาน OneLake
อนุญาตสิทธิ์ SQL สําหรับออบเจ็กต์ที่ไม่ใช่ข้อมูล เช่น มุมมอง กระบวนงานที่เก็บไว้ และฟังก์ชัน ทําให้มีความยืดหยุ่นในการกําหนดตรรกะแบบกําหนดเองหรือจุดเข้าใช้งานข้อมูลที่ผู้ใช้ต้องเผชิญ
การดําเนินการเขียนไม่ได้รับการสนับสนุนที่จุดสิ้นสุดการวิเคราะห์ SQL การเขียนทั้งหมดต้องเกิดขึ้นผ่านหน้า Lakehouse ในพอร์ทัล Fabric และอยู่ภายใต้การควบคุมโดยบทบาทพื้นที่ทํางาน (ผู้ดูแลระบบ สมาชิก ผู้สนับสนุน)
สําคัญ
จุดสิ้นสุด SQL Analytics ต้องการการแมปแบบตัวต่อตัวระหว่างสิทธิ์ของรายการและสมาชิกในบทบาทความปลอดภัย OneLake เพื่อซิงค์อย่างถูกต้อง หากคุณให้สิทธิ์ identity access to an securityrole OneLake ข้อมูลประจําตัวเดียวกันนั้นจะต้องมีสิทธิ์ Fabric Read ไปยังเลคเฮาส์ด้วย ตัวอย่างเช่น ถ้าผู้ใช้กําหนด "user123@microsoft.com" ให้กับ Security role ของ OneLake จะต้องกําหนด "user123@microsoft.com" ให้กับเลคเฮาส์นั้นด้วย
พฤติกรรมบทบาทพื้นที่ทํางาน
ผู้ใช้ที่มีบทบาท ผู้ดูแลระบบสมาชิก หรือ ผู้สนับสนุน ในระดับพื้นที่ทํางานจะไม่อยู่ภายใต้การบังคับใช้ความปลอดภัยของ OneLake บทบาทเหล่านี้มีสิทธิพิเศษที่สูงขึ้นและจะข้ามนโยบาย RLS, CLS และ OLS โดยสิ้นเชิง ปฏิบัติตามข้อกําหนดเหล่านี้เพื่อให้แน่ใจว่าความปลอดภัยของ OneLake ได้รับการเคารพ:
กําหนดบทบาท ผู้ชม ในพื้นที่ทํางานให้กับผู้ใช้ หรือ
แชร์ตําแหน่งข้อมูลการวิเคราะห์ Lakehouse หรือ SQL กับผู้ใช้โดยใช้สิทธิ์แบบอ่านอย่างเดียว เฉพาะผู้ใช้ที่มี read-only access เท่านั้นที่มีการกรองคิวรีตาม Security role ของ OneLake
ลําดับความสําคัญของบทบาท: Most permissive access wins
หากผู้ใช้อยู่ใน บทบาท OneLake หลายบทบาท บทบาทที่อนุญาตมากที่สุดจะกําหนด access ที่มีประสิทธิภาพ เช่น:
หากบทบาทหนึ่งให้ access เต็มรูปแบบแก่ตาราง และอีกบทบาทหนึ่งใช้ RLS เพื่อจํากัดแถว ระบบจะไม่บังคับใช้ RLS
บทบาท access ที่กว้างขึ้นมีความสําคัญเหนือกว่า ลักษณะการทํางานนี้ช่วยให้แน่ใจว่าผู้ใช้จะไม่ถูกบล็อกโดยไม่ได้ตั้งใจ แต่ต้องมีการออกแบบบทบาทอย่างรอบคอบเพื่อหลีกเลี่ยงความขัดแย้ง ขอแนะนําให้เก็บบทบาทที่จํากัดและอนุญาต ไม่รวมกัน เมื่อบังคับใช้ตัวควบคุม access ระดับแถวหรือคอลัมน์
สําหรับข้อมูลเพิ่มเติม โปรดดูแบบจําลอง access controldata สําหรับความปลอดภัยของ OneLake
การซิงค์ความปลอดภัยระหว่าง OneLake และปลายทางการวิเคราะห์ SQL
องค์ประกอบที่สําคัญของโหมดข้อมูลประจําตัวผู้ใช้คือบริการซิงค์ความปลอดภัย บริการเบื้องหลังนี้จะตรวจสอบการเปลี่ยนแปลงที่เกิดขึ้นกับบทบาทความปลอดภัยใน OneLake และทําให้แน่ใจว่าการเปลี่ยนแปลงเหล่านั้นจะสะท้อนให้เห็นในตําแหน่งข้อมูลการวิเคราะห์ SQL
บริการซิงค์ความปลอดภัยมีหน้าที่รับผิดชอบดังต่อไปนี้:
การตรวจจับการเปลี่ยนแปลงบทบาท OneLake รวมถึงบทบาทใหม่ การอัปเดต การกําหนดผู้ใช้ และการเปลี่ยนแปลงตาราง
การแปลนโยบายที่กําหนดโดย OneLake (RLS, CLS, OLS) เป็นโครงสร้างบทบาทฐานข้อมูลที่เข้ากันได้กับ SQL ที่เทียบเท่า
ตรวจสอบให้แน่ใจว่า ออบเจ็กต์ทางลัด (ตารางที่มาจากเลคเฮาส์อื่นๆ) ได้รับการตรวจสอบอย่างเหมาะสมเพื่อให้การตั้งค่าความปลอดภัย OneLake ดั้งเดิมได้รับการปฏิบัติตาม แม้ว่าจะเข้าถึงจากระยะไกลก็ตาม
การซิงโครไนซ์นี้ช่วยให้มั่นใจได้ว่าคําจํากัดความด้านความปลอดภัยของ OneLake ยังคงมีอํานาจ ทําให้ไม่จําเป็นต้องมีการแทรกแซงระดับ SQL ด้วยตนเองเพื่อจําลองพฤติกรรมความปลอดภัย เนื่องจากการรักษาความปลอดภัยถูกบังคับใช้จากส่วนกลาง:
คุณไม่สามารถกําหนด RLS, CLS หรือ OLS ได้โดยตรงโดยใช้ T-SQL ในโหมดนี้
คุณยังคงสามารถใช้สิทธิ์ SQL กับมุมมอง ฟังก์ชัน และกระบวนงานที่เก็บไว้โดยใช้คําสั่ง GRANT หรือ EXECUTE
ข้อผิดพลาดและการแก้ไขการซิงค์ความปลอดภัย
| สถานการณ์สมมติ | ลักษณะการทํางานในโหมดข้อมูลประจําตัวผู้ใช้ | ลักษณะการทํางานในโหมดที่ได้รับมอบหมาย | การดําเนินการแก้ไข | บันทึกย่อ |
|---|---|---|---|---|
| นโยบาย RLS อ้างอิงคอลัมน์ที่ถูกลบหรือเปลี่ยนชื่อ | ข้อผิดพลาด: *นโยบายความปลอดภัยระดับแถวอ้างอิงคอลัมน์ที่ไม่มีอยู่อีกต่อไป*ฐานข้อมูลจะเข้าสู่สถานะข้อผิดพลาดจนกว่านโยบายจะได้รับการแก้ไข | ข้อผิดพลาด: ชื่อ<คอลัมน์ชื่อ>คอลัมน์ไม่ถูกต้อง | อัปเดตหรือลบบทบาทที่ได้รับผลกระทบอย่างน้อยหนึ่งบทบาท หรือคืนค่าคอลัมน์ที่ขาดหายไป | การอัปเดตจะต้องทําในเลคเฮาส์ที่สร้างบทบาท |
| นโยบาย CLS อ้างอิงคอลัมน์ที่ถูกลบหรือเปลี่ยนชื่อ | ข้อผิดพลาด: *นโยบายความปลอดภัยระดับคอลัมน์อ้างอิงคอลัมน์ที่ไม่มีอยู่อีกต่อไป*ฐานข้อมูลเข้าสู่สถานะข้อผิดพลาดจนกว่านโยบายจะได้รับการแก้ไข | ข้อผิดพลาด: ชื่อ<คอลัมน์ชื่อ>คอลัมน์ไม่ถูกต้อง | อัปเดตหรือลบบทบาทที่ได้รับผลกระทบอย่างน้อยหนึ่งบทบาท หรือคืนค่าคอลัมน์ที่ขาดหายไป | การอัปเดตจะต้องทําในเลคเฮาส์ที่สร้างบทบาท |
| นโยบาย RLS/CLS อ้างอิงตารางที่ถูกลบหรือเปลี่ยนชื่อ | ข้อผิดพลาด: นโยบายความปลอดภัยอ้างอิงตารางที่ไม่มีอยู่อีกต่อไป | ไม่มีข้อผิดพลาดปรากฏขึ้น แบบสอบถามล้มเหลวอย่างเงียบ ๆ หากตารางหายไป | อัปเดตหรือลบบทบาทที่ได้รับผลกระทบอย่างน้อยหนึ่งบทบาท หรือกู้คืนตารางที่ขาดหายไป | การอัปเดตจะต้องทําในเลคเฮาส์ที่สร้างบทบาท |
| นโยบาย DDM (การมาสก์ข้อมูลแบบไดนามิก) อ้างอิงคอลัมน์ที่ถูกลบหรือเปลี่ยนชื่อ | DDM ไม่รองรับการรักษาความปลอดภัย OneLake ต้องใช้งานผ่าน SQL | ข้อผิดพลาด: ชื่อ<คอลัมน์ชื่อ>คอลัมน์ไม่ถูกต้อง | อัปเดตหรือลบกฎ DDM ที่ได้รับผลกระทบอย่างน้อยหนึ่งข้อ หรือคืนค่าคอลัมน์ที่หายไป | อัปเดตนโยบาย DDM ในปลายทาง SQL Analytics |
| ข้อผิดพลาดของระบบ (ความล้มเหลวที่ไม่คาดคิด) | ข้อผิดพลาด: เกิดข้อผิดพลาดของระบบที่ไม่คาดคิด ลองอีกครั้งหรือติดต่อฝ่ายสนับสนุน | ข้อผิดพลาด: มี ข้อผิดพลาดภายในเกิดขึ้นขณะนําการเปลี่ยนแปลงตารางไปใช้กับ SQL | ลองดําเนินการอีกครั้ง หากปัญหายังคงอยู่ โปรดติดต่อฝ่ายสนับสนุนของ Microsoft Support | ไม่มี |
| ผู้ใช้ไม่มีสิทธิ์ในสิ่งประดิษฐ์ | ข้อผิดพลาด: ผู้ใช้ไม่มีสิทธิ์ในสิ่งประดิษฐ์ | ข้อผิดพลาด: ผู้ใช้ไม่มีสิทธิ์ในสิ่งประดิษฐ์ | ให้สิทธิ์ objectID {objectID} แก่อาร์ติแฟกต์แก่ผู้ใช้ | รหัสออบเจ็กต์ต้องตรงกันทุกประการระหว่างสมาชิกบทบาทความปลอดภัย OneLake และสิทธิ์ของรายการ Fabric หากมีการเพิ่มกลุ่มในการเป็นสมาชิกบทบาท กลุ่มเดียวกันนั้นจะต้องได้รับสิทธิ์การอ่านแบบผ้า การเพิ่มสมาชิกจากกลุ่มนั้นไปยังรายการจะไม่นับเป็นการจับคู่โดยตรง |
| ไม่รองรับผู้ใช้หลัก | ข้อผิดพลาด: ไม่รองรับผู้ใช้หลัก | ข้อผิดพลาด: ไม่รองรับผู้ใช้หลัก | โปรดลบผู้ใช้ {ชื่อผู้ใช้} ออกจากบทบาท DefaultReader | ข้อผิดพลาดนี้เกิดขึ้นหากผู้ใช้ไม่ใช่ Entra ID ที่ถูกต้องอีกต่อไป เช่น หากผู้ใช้ออกจากองค์กรของคุณหรือถูกลบ ลบออกจากบทบาทเพื่อแก้ไขข้อผิดพลาดนี้ |
ลักษณะการทํางานของทางลัดที่มีการซิงค์ความปลอดภัย
การรักษาความปลอดภัย OneLake ถูกบังคับใช้ที่แหล่งที่มาของความจริง ดังนั้นการซิงค์ความปลอดภัยจึงปิดใช้งานการเชื่อมโยงความเป็นเจ้าของสําหรับตารางและมุมมองที่เกี่ยวข้องกับทางลัด สิ่งนี้ทําให้มั่นใจได้ว่าสิทธิ์ของระบบต้นทางจะได้รับการประเมินและให้เกียรติเสมอ
เป็นผลให้:
ผู้ใช้ต้องมี access ที่ถูกต้องใน ทั้งคู่ทางลัด source (ปลายทาง Lakehouse หรือ SQL Analytics ปัจจุบัน) และdestination ที่ข้อมูลอยู่จริง
หากผู้ใช้ไม่มีสิทธิ์ในด้านใดด้านหนึ่ง queries จะล้มเหลว โดยมีข้อผิดพลาด access
เมื่อออกแบบแอปพลิเคชันหรือมุมมองของคุณที่อ้างอิงทางลัด ให้ตรวจสอบให้แน่ใจว่ามีการกําหนดค่าการกําหนดบทบาทอย่างเหมาะสมที่ปลาย ทั้งสองด้าน ของความสัมพันธ์ทางลัด
การออกแบบนี้รักษาความสมบูรณ์ของความปลอดภัยข้ามขอบเขตของ Lakehouse แต่จะแนะนําสถานการณ์ที่อาจเกิดความล้มเหลว access หากบทบาทข้าม Lakehouse ไม่สอดคล้องกัน
โหมดที่ได้รับมอบหมายในการรักษาความปลอดภัย OneLake
ใน โหมดข้อมูลประจําตัวที่ได้รับมอบหมาย ตําแหน่งข้อมูลการวิเคราะห์ SQL จะใช้แบบจําลอง security เดียวกันที่มีอยู่ในปัจจุบัน ใน Microsoft Fabric ความปลอดภัยและสิทธิ์ได้รับการจัดการทั้งหมดที่เลเยอร์ SQL และบทบาท OneLake หรือนโยบาย access ไม่ได้บังคับใช้ สําหรับ access ระดับตาราง เมื่อผู้ใช้เชื่อมต่อกับตําแหน่งข้อมูลการวิเคราะห์ SQL และออกคิวรี:
SQL ตรวจสอบความถูกต้องของ access ตาม สิทธิ์ SQL (GRANT, REVOKE, RLS, CLS, DDM, บทบาท ฯลฯ)
หากคิวรีได้รับอนุญาต ระบบจะดําเนินการ access ข้อมูลที่จัดเก็บไว้ใน OneLake
access ข้อมูลนี้ดําเนินการโดยใช้ identity ของเจ้าของตําแหน่งข้อมูลการวิเคราะห์ Lakehouse หรือ SQL หรือที่เรียกว่า item
ในรุ่นนี้:
ผู้ใช้ที่ลงชื่อเข้าใช้จะไม่ถูกส่งผ่านไปยัง OneLake
การบังคับใช้ access ทั้งหมดจะถือว่าได้รับการจัดการที่เลเยอร์ SQL
เจ้าของรายการมีหน้าที่รับผิดชอบในการมีสิทธิ์เพียงพอใน OneLake เพื่ออ่านไฟล์พื้นฐานในนามของปริมาณงาน
เนื่องจากนี่เป็นรูปแบบที่ได้รับมอบหมาย ความไม่ตรงกันระหว่างสิทธิ์ SQL และ OneLake access สําหรับเจ้าของจะส่งผลให้คิวรีล้มเหลว โหมดนี้ให้ความเข้ากันได้อย่างสมบูรณ์กับ:
SQL GRANT/REVOKE ในทุกระดับออบเจ็กต์
ความปลอดภัยRow-Level ที่กําหนดโดย SQL, ความปลอดภัยของColumn-Level และการมาสก์ข้อมูลแบบไดนามิก
เครื่องมือและแนวทางปฏิบัติ T-SQL ที่มีอยู่ที่ใช้โดย DBA หรือแอปพลิเคชัน
วิธีเปลี่ยนโหมด OneLake access
โหมด access จะกําหนดวิธีการรับรองความถูกต้องและบังคับใช้ Data access เมื่อคิวรี OneLake ผ่านปลายทางการวิเคราะห์ SQL คุณสามารถสลับระหว่างโหมดข้อมูลประจําตัวผู้ใช้และโหมดข้อมูลประจําตัวที่ได้รับมอบหมายได้โดยใช้ขั้นตอนต่อไปนี้:
นําทางไปยังพื้นที่ทํางาน Fabric ของคุณและเปิดเลคเฮาส์ของคุณ จากมุมบนขวา ให้เปลี่ยนจากเลคเฮาส์เป็นปลายทางการวิเคราะห์ SQL
จากการนําทางด้านบน ไปที่แท็บ Security และเลือกโหมด access OneLake อย่างใดอย่างหนึ่งต่อไปนี้:
ข้อมูลประจําตัวของผู้ใช้ – ใช้ข้อมูลประจําตัวของผู้ใช้ที่ลงชื่อเข้าใช้ บังคับใช้บทบาทของ OneLake
ข้อมูลประจําตัวที่ได้รับมอบหมาย – ใช้ข้อมูลประจําตัวของเจ้าของสินค้า บังคับใช้เฉพาะสิทธิ์ SQL เท่านั้น
ป๊อปอัปจะเปิดขึ้นเพื่อยืนยันการเลือกของคุณ เลือก ใช่ เพื่อยืนยันการเปลี่ยนแปลง
ข้อควรพิจารณาเมื่อสลับระหว่างโหมดต่างๆ
สําคัญ
การสลับระหว่างโหมดข้อมูลประจําตัวผู้ใช้และโหมดที่ได้รับมอบหมาย (ในทิศทางใดทิศทางหนึ่ง) จะลบออบเจ็กต์ข้อมูลเมตาแบบอินไลน์ รวมถึง TVF และฟังก์ชัน Scalar-Valued ลักษณะการทํางานนี้มีผลกับคําจํากัดความของข้อมูลเมตาเท่านั้น ข้อมูลพื้นฐานใน OneLake จะไม่ได้รับผลกระทบ
การเปลี่ยนเป็นโหมดข้อมูลประจําตัวผู้ใช้
สิทธิ์ SQL RLS, CLS และระดับตารางจะถูกละเว้น
ต้องกําหนดค่าบทบาท OneLake สําหรับผู้ใช้เพื่อรักษา access
เฉพาะผู้ใช้ที่มีสิทธิ์ Viewer หรือ Share-Read-Only access เท่านั้นที่จะอยู่ภายใต้การรักษาความปลอดภัยของ OneLake
บทบาท SQL ที่มีอยู่จะถูกลบและไม่สามารถกู้คืนได้
การเปลี่ยนไปใช้โหมดข้อมูลประจําตัวที่ได้รับมอบหมาย
บทบาทและนโยบายความปลอดภัยของ OneLake จะไม่ถูกนําไปใช้อีกต่อไป
บทบาท SQL และนโยบายความปลอดภัยจะเปิดใช้งาน
เจ้าของรายการต้องมี OneLake access ที่ถูกต้อง มิฉะนั้น คิวรีทั้งหมดอาจล้มเหลว
แก้ไข ปัญหา
ในโหมด ข้อมูลประจําตัวของผู้ใช้ ผลการซิงค์ความปลอดภัยสามารถตรวจสอบความถูกต้องผ่าน UX ได้ เปิดตําแหน่งข้อมูล SQL Analytics ขยายโฟลเดอร์ ความปลอดภัย ใน Explorer จากนั้นเลือก บทบาท DB (กําหนดเอง) หากซิงค์สําเร็จ คุณจะเห็นบทบาทที่แสดงรายการด้วยคํานําหน้า "ols_" ตัวอย่างเช่น "ols_TestRole" ชื่อบทบาทที่มี "ols_{alphanumericString}_rolename" คือบทบาทจากเลคเฮาส์อื่นๆ ที่เผยแพร่ผ่านทางลัด
การแก้ไขข้อผิดพลาดการซิงค์ความปลอดภัยที่พบบ่อย
การซิงค์ความปลอดภัยจะล้มเหลวหากบทบาทใดอ้างอิงตารางที่ถูกทิ้ง ลบตารางเหล่านั้นออกจากบทบาท แล้วลองซิงค์ความปลอดภัยอีกครั้ง
SPN ไม่สามารถเป็นเจ้าของเลคเฮาส์ได้ ตรวจสอบให้แน่ใจว่ารายการเลคเฮาส์หลักเป็นของบัญชีผู้ใช้
สมาชิก Security role ของ OneLake ทั้งหมดต้องได้รับสิทธิ์การ อ่าน Fabric ให้กับเลคเฮาส์สําหรับการซิงค์ความปลอดภัยเพื่อจดจําผู้ใช้หรือกลุ่ม
Limitations
ใช้กับผู้อ่านเท่านั้น: การรักษาความปลอดภัยของ OneLake ควบคุมผู้ใช้ที่เข้าถึงข้อมูลในฐานะผู้ชม ผู้ใช้ในบทบาทพื้นที่ทํางานอื่นๆ (ผู้ดูแลระบบ สมาชิก หรือผู้สนับสนุน) จะข้ามการรักษาความปลอดภัยของ OneLake และรักษา access แบบเต็ม
วัตถุ SQL ไม่สืบทอดความเป็นเจ้าของ: ทางลัดจะปรากฏในตําแหน่งข้อมูลการวิเคราะห์ SQL เป็นตาราง เมื่อเข้าถึงตารางเหล่านี้โดยตรงหรือผ่านมุมมองกระบวนงานที่เก็บไว้และวัตถุ SQL ที่ได้รับอื่น ๆ จะไม่มีความเป็นเจ้าของระดับวัตถุ สิทธิ์ทั้งหมดจะถูกตรวจสอบในขณะรันไทม์เพื่อป้องกันการบายพาสความปลอดภัย
การเปลี่ยนแปลงทางลัดทริกเกอร์เวลาหยุดทํางานของการตรวจสอบความถูกต้อง: เมื่อเป้าหมายทางลัดเปลี่ยนไป (ตัวอย่างเช่น เปลี่ยนชื่อ การอัปเดต URL) ฐานข้อมูลจะเข้าสู่ โหมดผู้ใช้คนเดียว ชั่วครู่ในขณะที่ระบบตรวจสอบความถูกต้องของเป้าหมายใหม่ ในช่วงเวลานี้การสืบค้นจะถูกบล็อกการดําเนินการเหล่านี้ค่อนข้างรวดเร็ว แต่บางครั้งขึ้นอยู่กับกระบวนการภายในที่แตกต่างกันอาจใช้เวลาถึง 5 นาทีในการซิงโครไนซ์
- การสร้างทางลัดสคีมาอาจทําให้เกิดข้อผิดพลาดที่ทราบซึ่งส่งผลต่อการตรวจสอบความถูกต้องและทําให้การซิงค์ข้อมูลเมตาล่าช้า
การเผยแพร่สิทธิ์ล่าช้า: การเปลี่ยนแปลงสิทธิ์ไม่ได้เกิดขึ้นในทันที การสลับระหว่างโหมดความปลอดภัย (ข้อมูลประจําตัวผู้ใช้เทียบกับผู้รับมอบสิทธิ์) อาจต้องใช้เวลาในการเผยแพร่ก่อนที่จะมีผล แต่ควรใช้เวลาน้อยกว่า 1 นาที
การขึ้นกันของระนาบควบคุม: ไม่สามารถนําสิทธิ์ไปใช้กับผู้ใช้หรือกลุ่มที่ไม่มีอยู่ในระนาบควบคุมพื้นที่ทํางานได้ คุณต้องใช้ข้อมูลต้นฉบับร่วมกัน หรือผู้ใช้ต้องเป็นสมาชิกของบทบาทพื้นที่ทํางานของผู้ดู โปรดทราบว่ารหัสออบเจ็กต์เดียวกันทุกประการต้องอยู่ในทั้งสองตําแหน่ง กลุ่มและสมาชิกของกลุ่มนั้นจะไม่นับเป็นการจับคู่
access ที่อนุญาตมากที่สุดมีชัย: เมื่อผู้ใช้อยู่ในหลายกลุ่มหรือหลายบทบาท จะให้เกียรติสิทธิ์ที่มีผลบังคับใช้มากที่สุด ตัวอย่าง: หากผู้ใช้มีทั้ง DENY ผ่านบทบาทหนึ่งและ GRANT ผ่านอีกบทบาทหนึ่ง GRANT จะมีความสําคัญเหนือกว่า
ข้อจํากัดของโหมดที่ได้รับมอบหมาย: ในโหมดที่ได้รับมอบหมาย การซิงค์ข้อมูลเมตาบนตารางทางลัดอาจล้มเหลวหากรายการต้นทางมีนโยบายความปลอดภัยของ OneLake ที่ไม่ให้ access ตารางแบบเต็มแก่เจ้าของรายการ
ลักษณะการทํางานของ SQL Server DENY: เมื่อมีหลายบทบาทนําไปใช้กับตารางทางลัดเดียว จุดตัดของสิทธิ์จะเป็นไปตามความหมาย: DENY แทนที่ GRANT สิ่งนี้สามารถสร้างผลลัพธ์ access ที่ไม่คาดคิด
เงื่อนไขข้อผิดพลาดที่คาดไว้: ผู้ใช้อาจพบข้อผิดพลาดในสถานการณ์ต่างๆ เช่น:
เป้าหมายทางลัดเปลี่ยนชื่อหรือไม่ถูกต้อง
- ตัวอย่าง: หากแหล่งที่มาของตารางถูกลบ
การกําหนดค่า RLS (Row-Level Security) ผิดพลาด
นิพจน์บางนิพจน์สําหรับการกรอง RLS ไม่ได้รับการสนับสนุนใน OneLake และอาจอนุญาตให้ access ข้อมูลโดยไม่ได้รับอนุญาต
การทิ้งคอลัมน์ที่ใช้ในนิพจน์ตัวกรองจะทําให้ RLS เป็นโมฆะ และการซิงค์ข้อมูลเมตาจะเก่าจนกว่า RLS จะได้รับการแก้ไขบนแผงความปลอดภัย OneLake
สําหรับการแสดงตัวอย่างสาธารณะ เราสนับสนุนเฉพาะตารางนิพจน์เดียวเท่านั้น RLS แบบไดนามิกและ RLS หลายตารางไม่ได้รับการสนับสนุนในขณะนี้
ข้อจํากัดด้านความปลอดภัย (CLS) Column-Level
CLS ทํางานโดยรักษารายการคอลัมน์ที่อนุญาต ถ้าคอลัมน์ที่อนุญาตถูกลบออกหรือเปลี่ยนชื่อ นโยบาย CLS จะไม่ถูกต้อง
เมื่อ CLS ไม่ถูกต้อง การซิงค์ข้อมูลเมตาจะถูกบล็อกจนกว่ากฎ CLS จะได้รับการแก้ไขในแผงความปลอดภัยของ OneLake
ข้อมูลเมตาหรือการซิงค์สิทธิ์ล้มเหลว
- หากมีการเปลี่ยนแปลงในตาราง เช่น การเปลี่ยนชื่อคอลัมน์ ความปลอดภัยจะไม่ถูกจําลองแบบบนออบเจ็กต์ใหม่ และคุณได้รับข้อผิดพลาด UI ที่แสดงว่าไม่มีคอลัมน์
การเปลี่ยนชื่อตารางไม่ได้รักษานโยบายความปลอดภัย: ถ้ามีการกําหนดบทบาทความปลอดภัย OneLake (OLS) ในระดับ Schema บทบาทเหล่านั้นจะยังคงมีผลตราบเท่าที่ชื่อตารางไม่เปลี่ยนแปลง การเปลี่ยนชื่อตารางจะทําลายการเชื่อมโยง และนโยบายความปลอดภัยจะไม่ถูกโยกย้ายโดยอัตโนมัติ ซึ่งอาจส่งผลให้เกิดการเปิดเผยข้อมูลโดยไม่ได้ตั้งใจจนกว่าจะใช้นโยบายอีกครั้ง
บทบาทความปลอดภัยของ OneLake ต้องไม่มีชื่อที่ยาวกว่า 124 อักขระ มิฉะนั้น การซิงค์ความปลอดภัยจะไม่สามารถซิงโครไนส์บทบาทได้
การเปลี่ยนแปลงของผู้ใช้ในบทบาท OLS_ ไม่ได้รับการสนับสนุน และอาจทําให้เกิดลักษณะการทํางานที่ไม่คาดคิด
กลุ่มความปลอดภัยและรายชื่อการแจกจ่ายที่เปิดใช้งานจดหมายไม่ได้รับการสนับสนุน
เจ้าของเลคเฮาส์ต้องเป็นสมาชิกของบทบาทพื้นที่ทํางานของผู้ดูแลระบบ สมาชิก หรือผู้สนับสนุน มิฉะนั้น การรักษาความปลอดภัยจะไม่ถูกนําไปใช้กับตําแหน่งข้อมูลการวิเคราะห์ SQL
เจ้าของเลคเฮาส์ไม่สามารถเป็นบริการหลักสําหรับการซิงค์ความปลอดภัยในการทํางาน