หมายเหตุ
การเข้าถึงหน้านี้ต้องได้รับการอนุญาต คุณสามารถลอง ลงชื่อเข้าใช้หรือเปลี่ยนไดเรกทอรีได้
การเข้าถึงหน้านี้ต้องได้รับการอนุญาต คุณสามารถลองเปลี่ยนไดเรกทอรีได้
ด้วยการรักษาความปลอดภัยของ OneLake ทําให้ Microsoft Fabric กําลังขยายวิธีที่องค์กรสามารถจัดการและบังคับใช้การเข้าถึงข้อมูลในปริมาณงานต่างๆ เฟรมเวิร์กการรักษาความปลอดภัยใหม่นี้ช่วยให้ผู้ดูแลระบบมีความยืดหยุ่นมากขึ้นในการกําหนดค่าสิทธิ์ ผู้ดูแลระบบสามารถเลือกระหว่าง การกํากับดูแลแบบรวมศูนย์ผ่าน OneLake หรือ การควบคุมแบบ SQL แบบละเอียด ภายในตําแหน่งข้อมูลการวิเคราะห์ SQL
โหมดการเข้าถึงในตําแหน่งข้อมูลการวิเคราะห์ SQL
เมื่อใช้ ตําแหน่งข้อมูลการวิเคราะห์ SQL โหมดการเข้าถึงที่เลือกจะกําหนดวิธีการบังคับใช้ความปลอดภัยของข้อมูล Fabric รองรับรูปแบบการเข้าถึงที่แตกต่างกันสองรูปแบบ โดยแต่ละรุ่นให้ประโยชน์ที่แตกต่างกันขึ้นอยู่กับความต้องการด้านการดําเนินงานและการปฏิบัติตามข้อกําหนดของคุณ:
โหมดข้อมูลประจําตัวของผู้ใช้: บังคับใช้การรักษาความปลอดภัยโดยใช้บทบาทและนโยบายของ OneLake ในโหมดนี้ จุดสิ้นสุดการวิเคราะห์ SQL จะส่งข้อมูลประจําตัวของผู้ใช้ที่ลงชื่อเข้าใช้ไปยัง OneLake และ การเข้าถึงการอ่านจะถูกควบคุมโดยกฎความปลอดภัยที่กําหนดไว้ภายใน OneLake ทั้งหมด รองรับสิทธิ์ระดับ SQL บนตาราง เพื่อให้มั่นใจว่าการกํากับดูแลที่สอดคล้องกันในเครื่องมือต่างๆ เช่น Power BI, โน้ตบุ๊ก และเลคเฮาส์
โหมดข้อมูลประจําตัวที่ได้รับมอบหมาย: ให้การควบคุมเต็มรูปแบบผ่าน SQL ในโหมดนี้ จุดสิ้นสุดการวิเคราะห์ SQL จะเชื่อมต่อกับ OneLake โดยใช้ข้อมูลประจําตัวของ พื้นที่ทํางานหรือเจ้าของรายการ และ ความปลอดภัยจะถูกควบคุมโดยสิทธิ์ SQL ที่กําหนดไว้ภายในฐานข้อมูลเท่านั้น โมเดลนี้รองรับแนวทางการรักษาความปลอดภัยแบบดั้งเดิม รวมถึง GRANT, REVOKE, บทบาทที่กําหนดเอง, Row-Level Security และ Dynamic Data Masking
แต่ละโหมดรองรับรูปแบบการกํากับดูแลที่แตกต่างกัน การทําความเข้าใจความหมายเป็นสิ่งสําคัญสําหรับการเลือกแนวทางที่เหมาะสมในสภาพแวดล้อม Fabric ของคุณ
การเปรียบเทียบระหว่างโหมดการเข้าถึง
ต่อไปนี้คือตารางเปรียบเทียบที่ชัดเจนและรัดกุมโดยเน้นวิธีการและตําแหน่งที่คุณตั้งค่าความปลอดภัยในโหมดข้อมูลประจําตัวของผู้ใช้เทียบกับโหมดข้อมูลประจําตัวที่ได้รับมอบหมาย โดยแบ่งตามประเภทอ็อบเจ็กต์และนโยบายการเข้าถึงข้อมูล:
| เป้าหมายความปลอดภัย | โหมดการระบุตัวตนของผู้ใช้ | โหมดข้อมูลประจําตัวที่ได้รับมอบหมาย |
|---|---|---|
| ตาราง | การเข้าถึงถูกควบคุมโดยบทบาทความปลอดภัยของ 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 จะใช้ กลไกการรับรองความถูกต้องแบบพาสทรู เพื่อบังคับใช้การเข้าถึงข้อมูล เมื่อผู้ใช้เชื่อมต่อกับตําแหน่งข้อมูลการวิเคราะห์ SQL ข้อมูลประจําตัว Entra ID ของพวกเขาจะถูกส่งผ่านไปยัง OneLake ซึ่งจะทําการตรวจสอบสิทธิ์ การดําเนินการอ่านทั้งหมดกับตารางจะได้รับการประเมินโดยใช้กฎความปลอดภัยที่กําหนดไว้ใน OneLake Lakehouse ไม่ใช่โดยคําสั่ง GRANT หรือ REVOKE ระดับ SQL
โหมดนี้ช่วยให้คุณสามารถจัดการความปลอดภัยจากส่วนกลาง เพื่อให้มั่นใจว่าการบังคับใช้ที่สอดคล้องกันในประสบการณ์ Fabric ทั้งหมด รวมถึง Power BI, สมุดบันทึก, เลคเฮาส์ และปลายทางการวิเคราะห์ SQL ออกแบบมาสําหรับโมเดลการกํากับดูแลที่ควรกําหนดการเข้าถึงเพียงครั้งเดียวใน OneLake และเคารพโดยอัตโนมัติทุกที่
ในโหมดข้อมูลประจําตัวผู้ใช้:
การเข้าถึงตารางถูกควบคุมโดยความปลอดภัยของ OneLake ทั้งหมด คําสั่ง SQL GRANT/REVOKE บนตารางจะถูกละเว้น
RLS (Row-Level Security), CLS (Column-Level Security) และ Object-Level Security ทั้งหมดถูกกําหนดไว้ในประสบการณ์การใช้งาน OneLake
อนุญาตสิทธิ์ SQL สําหรับออบเจ็กต์ที่ไม่ใช่ข้อมูล เช่น มุมมอง กระบวนงานที่เก็บไว้ และฟังก์ชัน ทําให้มีความยืดหยุ่นในการกําหนดตรรกะแบบกําหนดเองหรือจุดเข้าใช้งานข้อมูลที่ผู้ใช้ต้องเผชิญ
การดําเนินการเขียนไม่ได้รับการสนับสนุนที่จุดสิ้นสุดการวิเคราะห์ SQL การเขียนทั้งหมดต้องเกิดขึ้นผ่าน Lakehouse UI และอยู่ภายใต้การควบคุมโดยบทบาทพื้นที่ทํางาน (ผู้ดูแลระบบ สมาชิก ผู้สนับสนุน)
สําคัญ
จุดสิ้นสุด SQL Analytics ต้องการการแมปแบบตัวต่อตัวระหว่างสิทธิ์ของรายการและสมาชิกในบทบาทความปลอดภัย OneLake เพื่อซิงค์อย่างถูกต้อง ถ้าคุณให้สิทธิ์การเข้าถึงข้อมูลประจําตัวไปยัง Security role ของ OneLake ข้อมูลประจําตัวเดียวกันนั้นจะต้องมีสิทธิ์การอ่าน Fabric ไปยังเลคเฮาส์ด้วย ตัวอย่างเช่น ถ้าผู้ใช้กําหนด "user123@microsoft.com" ให้กับ Security role ของ OneLake จะต้องกําหนด "user123@microsoft.com" ให้กับเลคเฮาส์นั้นด้วย
พฤติกรรมบทบาทพื้นที่ทํางาน
ผู้ใช้ที่มีบทบาท ผู้ดูแลระบบสมาชิก หรือ ผู้สนับสนุน ในระดับพื้นที่ทํางานจะไม่อยู่ภายใต้การบังคับใช้ความปลอดภัยของ OneLake บทบาทเหล่านี้มีสิทธิพิเศษที่สูงขึ้นและจะข้ามนโยบาย RLS, CLS และ OLS โดยสิ้นเชิง ปฏิบัติตามข้อกําหนดเหล่านี้เพื่อให้แน่ใจว่าความปลอดภัยของ OneLake ได้รับการเคารพ:
กําหนดบทบาท ผู้ชม ในพื้นที่ทํางานให้กับผู้ใช้ หรือ
แชร์ตําแหน่งข้อมูลการวิเคราะห์ Lakehouse หรือ SQL กับผู้ใช้โดยใช้สิทธิ์แบบอ่านอย่างเดียว เฉพาะผู้ใช้ที่มีสิทธิ์เข้าถึงแบบอ่านอย่างเดียวเท่านั้นที่มีการกรองคิวรีตาม Security role ของ OneLake
ลําดับความสําคัญของบทบาท: การเข้าถึงที่อนุญาตมากที่สุดจะชนะ
หากผู้ใช้อยู่ใน บทบาท OneLake หลายบทบาท บทบาทที่อนุญาตมากที่สุดจะกําหนดการเข้าถึงที่มีประสิทธิภาพ เช่น:
หากบทบาทหนึ่งให้สิทธิ์การเข้าถึงตารางอย่างเต็มรูปแบบ และอีกบทบาทหนึ่งใช้ RLS เพื่อจํากัดแถว RLS จะไม่ถูกบังคับใช้
บทบาทการเข้าถึงที่กว้างขึ้นมีความสําคัญเหนือกว่า ลักษณะการทํางานนี้ช่วยให้แน่ใจว่าผู้ใช้จะไม่ถูกบล็อกโดยไม่ได้ตั้งใจ แต่ต้องมีการออกแบบบทบาทอย่างรอบคอบเพื่อหลีกเลี่ยงความขัดแย้ง ขอแนะนําให้เก็บบทบาทที่จํากัดและอนุญาต ไว้ซึ่งกันและกัน เมื่อบังคับใช้การควบคุมการเข้าถึงระดับแถวหรือคอลัมน์
สําหรับข้อมูลเพิ่มเติม โปรดดู แบบจําลองการควบคุมการเข้าถึงข้อมูล สําหรับความปลอดภัยของ 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 Security ต้องใช้งานผ่าน SQL | ข้อผิดพลาด: ชื่อ<คอลัมน์ชื่อ>คอลัมน์ไม่ถูกต้อง | อัปเดตหรือลบกฎ DDM ที่ได้รับผลกระทบอย่างน้อยหนึ่งข้อ หรือคืนค่าคอลัมน์ที่หายไป | อัปเดตนโยบาย DDM ในปลายทาง SQL Analytics |
| ข้อผิดพลาดของระบบ (ความล้มเหลวที่ไม่คาดคิด) | ข้อผิดพลาด: เกิดข้อผิดพลาดของระบบที่ไม่คาดคิด ลองอีกครั้งหรือติดต่อฝ่ายสนับสนุน | ข้อผิดพลาด: มี ข้อผิดพลาดภายในเกิดขึ้นขณะนําการเปลี่ยนแปลงตารางไปใช้กับ SQL | ลองดําเนินการอีกครั้ง หากปัญหายังคงอยู่ โปรดติดต่อฝ่ายสนับสนุนของ Microsoft | ไม่มี |
| ผู้ใช้ไม่มีสิทธิ์ในสิ่งประดิษฐ์ | ข้อผิดพลาด: ผู้ใช้ไม่มีสิทธิ์ในสิ่งประดิษฐ์ | ข้อผิดพลาด: ผู้ใช้ไม่มีสิทธิ์ในสิ่งประดิษฐ์ | ให้สิทธิ์ objectID {objectID} แก่อาร์ติแฟกต์แก่ผู้ใช้ | รหัสออบเจ็กต์ต้องตรงกันทุกประการระหว่างสมาชิกบทบาทความปลอดภัย OneLake และสิทธิ์ของรายการ Fabric หากมีการเพิ่มกลุ่มในการเป็นสมาชิกบทบาท กลุ่มเดียวกันนั้นจะต้องได้รับสิทธิ์การอ่านแบบผ้า การเพิ่มสมาชิกจากกลุ่มนั้นไปยังรายการจะไม่นับเป็นการจับคู่โดยตรง |
| ไม่รองรับผู้ใช้หลัก | ข้อผิดพลาด: ไม่รองรับผู้ใช้หลัก | ข้อผิดพลาด: ไม่รองรับผู้ใช้หลัก | โปรดลบผู้ใช้ {ชื่อผู้ใช้} ออกจากบทบาท DefaultReader | ข้อผิดพลาดนี้เกิดขึ้นหากผู้ใช้ไม่ใช่ Entra ID ที่ถูกต้องอีกต่อไป เช่น หากผู้ใช้ออกจากองค์กรของคุณหรือถูกลบ ลบออกจากบทบาทเพื่อแก้ไขข้อผิดพลาดนี้ |
ลักษณะการทํางานของทางลัดที่มีการซิงค์ความปลอดภัย
การรักษาความปลอดภัย OneLake ถูกบังคับใช้ที่แหล่งที่มาของความจริง ดังนั้นการซิงค์ความปลอดภัยจึงปิดใช้งานการเชื่อมโยงความเป็นเจ้าของสําหรับตารางและมุมมองที่เกี่ยวข้องกับทางลัด สิ่งนี้ทําให้มั่นใจได้ว่าสิทธิ์ของระบบต้นทางจะได้รับการประเมินและให้เกียรติเสมอ
เป็นผลให้:
ผู้ใช้ต้องมีสิทธิ์เข้าถึงที่ถูกต้องทั้งในแหล่งข้อมูลทางลัด (ตําแหน่งข้อมูล Lakehouse หรือ SQL Analytics ปัจจุบัน) และปลายทางที่ข้อมูลอยู่จริง
หากผู้ใช้ไม่มีสิทธิ์จากด้านใดด้านหนึ่ง การ สืบค้นจะล้มเหลว โดยมีข้อผิดพลาดในการเข้าถึง
เมื่อออกแบบแอปพลิเคชันหรือมุมมองของคุณที่อ้างอิงทางลัด ให้ตรวจสอบให้แน่ใจว่ามีการกําหนดค่าการกําหนดบทบาทอย่างเหมาะสมที่ปลาย ทั้งสองด้าน ของความสัมพันธ์ทางลัด
การออกแบบนี้รักษาความสมบูรณ์ของความปลอดภัยข้ามขอบเขตของ Lakehouse แต่จะแนะนําสถานการณ์ที่ความล้มเหลวในการเข้าถึงอาจเกิดขึ้นหากบทบาทข้าม Lakehouse ไม่สอดคล้องกัน
โหมดที่ได้รับมอบหมายในการรักษาความปลอดภัย OneLake
ในโหมด ข้อมูลประจําตัวที่ได้รับมอบหมาย ปลายทางการวิเคราะห์ SQL จะใช้ แบบจําลองความปลอดภัย เดียวกันที่มีอยู่ในปัจจุบันใน Microsoft Fabric การรักษาความปลอดภัยและสิทธิ์ได้รับการจัดการทั้งหมดที่เล เยอร์ SQL และบทบาท OneLake หรือนโยบายการเข้าถึงจะไม่ถูกบังคับใช้สําหรับ การเข้าถึงระดับตาราง เมื่อผู้ใช้เชื่อมต่อกับตําแหน่งข้อมูลการวิเคราะห์ SQL และออกคิวรี:
SQL ตรวจสอบการเข้าถึงตาม สิทธิ์ SQL (GRANT, REVOKE, RLS, CLS, DDM, บทบาท ฯลฯ)
หากการสืบค้นได้รับอนุญาต ระบบจะดําเนินการเข้าถึงข้อมูลที่จัดเก็บไว้ใน OneLake
การเข้าถึงข้อมูลนี้ดําเนินการโดยใช้ข้อมูลประจําตัวของเจ้าของตําแหน่งข้อมูลการวิเคราะห์ Lakehouse หรือ SQL หรือที่เรียกว่าบัญชีรายการ
ในรุ่นนี้:
ผู้ใช้ที่ลงชื่อเข้าใช้จะไม่ถูกส่งผ่านไปยัง OneLake
การบังคับใช้การเข้าถึงทั้งหมดถือว่าได้รับการจัดการที่เลเยอร์ SQL
เจ้าของรายการมีหน้าที่รับผิดชอบในการมีสิทธิ์เพียงพอใน OneLake เพื่ออ่านไฟล์พื้นฐานในนามของปริมาณงาน
เนื่องจากเป็นรูปแบบที่ได้รับมอบหมาย ความไม่ตรงแนวระหว่างสิทธิ์ SQL และการเข้าถึง OneLake สําหรับเจ้าของจะส่งผลให้คิวรีล้มเหลว โหมดนี้ให้ความเข้ากันได้อย่างสมบูรณ์กับ:
SQL GRANT/REVOKE ในทุกระดับออบเจ็กต์
ความปลอดภัยRow-Level ที่กําหนดโดย SQL, ความปลอดภัยของColumn-Level และการมาสก์ข้อมูลแบบไดนามิก
เครื่องมือและแนวทางปฏิบัติ T-SQL ที่มีอยู่ที่ใช้โดย DBA หรือแอปพลิเคชัน
วิธีเปลี่ยนโหมดการเข้าถึง OneLake
โหมดการเข้าถึงจะกําหนดวิธีการรับรองความถูกต้องและบังคับใช้การเข้าถึงข้อมูลเมื่อคิวรี OneLake ผ่านจุดสิ้นสุดการวิเคราะห์ SQL คุณสามารถสลับระหว่างโหมดข้อมูลประจําตัวผู้ใช้และโหมดข้อมูลประจําตัวที่ได้รับมอบหมายได้โดยใช้ขั้นตอนต่อไปนี้:
นําทางไปยังพื้นที่ทํางาน Fabric ของคุณและเปิดเลคเฮาส์ของคุณ จากมุมบนขวา ให้เปลี่ยนจากเลคเฮาส์เป็นปลายทางการวิเคราะห์ SQL
จากการนําทางด้านบน ให้ไปที่แท็บ ความปลอดภัย และเลือกโหมดการเข้าถึง OneLake โหมดใดโหมดหนึ่งต่อไปนี้:
ข้อมูลประจําตัวของผู้ใช้ – ใช้ข้อมูลประจําตัวของผู้ใช้ที่ลงชื่อเข้าใช้ บังคับใช้บทบาทของ OneLake
ข้อมูลประจําตัวที่ได้รับมอบหมาย – ใช้ข้อมูลประจําตัวของเจ้าของสินค้า บังคับใช้เฉพาะสิทธิ์ SQL เท่านั้น
ป๊อปอัปจะเปิดขึ้นเพื่อยืนยันการเลือกของคุณ เลือก ใช่ เพื่อยืนยันการเปลี่ยนแปลง
ข้อควรพิจารณาเมื่อสลับระหว่างโหมดต่างๆ
การเปลี่ยนเป็นโหมดข้อมูลประจําตัวผู้ใช้
สิทธิ์ SQL RLS, CLS และระดับตารางจะถูกละเว้น
ต้องกําหนดค่าบทบาท OneLake สําหรับผู้ใช้เพื่อรักษาการเข้าถึง
เฉพาะผู้ใช้ที่มีสิทธิ์ Viewer หรือการเข้าถึงแบบอ่านอย่างเดียวที่ใช้ร่วมกันเท่านั้นที่จะอยู่ภายใต้การรักษาความปลอดภัยของ OneLake
บทบาท SQL ที่มีอยู่จะถูกลบและไม่สามารถกู้คืนได้
การเปลี่ยนไปใช้โหมดข้อมูลประจําตัวที่ได้รับมอบหมาย
บทบาทและนโยบายความปลอดภัยของ OneLake จะไม่ถูกนําไปใช้อีกต่อไป
บทบาท SQL และนโยบายความปลอดภัยจะเปิดใช้งาน
เจ้าของรายการต้องมีสิทธิ์เข้าถึง OneLake ที่ถูกต้อง มิฉะนั้น การสืบค้นทั้งหมดอาจล้มเหลว
Limitations
ใช้กับผู้อ่านเท่านั้น: OneLake Security ควบคุมผู้ใช้ที่เข้าถึงข้อมูลในฐานะผู้ชม ผู้ใช้ในบทบาทพื้นที่ทํางานอื่นๆ (ผู้ดูแลระบบ สมาชิก หรือผู้สนับสนุน) ข้าม OneLake Security และยังคงมีสิทธิ์เข้าถึงแบบเต็ม
วัตถุ SQL ไม่สืบทอดความเป็นเจ้าของ: ทางลัดจะปรากฏในตําแหน่งข้อมูลการวิเคราะห์ SQL เป็นตาราง เมื่อเข้าถึงตารางเหล่านี้โดยตรงหรือผ่านมุมมองกระบวนงานที่เก็บไว้และวัตถุ SQL ที่ได้รับอื่น ๆ จะไม่มีความเป็นเจ้าของระดับวัตถุ สิทธิ์ทั้งหมดจะถูกตรวจสอบในขณะรันไทม์เพื่อป้องกันการบายพาสความปลอดภัย
การเปลี่ยนแปลงทางลัดทริกเกอร์เวลาหยุดทํางานของการตรวจสอบความถูกต้อง: เมื่อเป้าหมายทางลัดเปลี่ยนไป (ตัวอย่างเช่น เปลี่ยนชื่อ การอัปเดต URL) ฐานข้อมูลจะเข้าสู่ โหมดผู้ใช้คนเดียว ชั่วครู่ในขณะที่ระบบตรวจสอบความถูกต้องของเป้าหมายใหม่ ในช่วงเวลานี้การสืบค้นจะถูกบล็อกการดําเนินการเหล่านี้ค่อนข้างรวดเร็ว แต่บางครั้งขึ้นอยู่กับกระบวนการภายในที่แตกต่างกันอาจใช้เวลาถึง 5 นาทีในการซิงโครไนซ์
- การสร้างทางลัดสคีมาอาจทําให้เกิดข้อผิดพลาดที่ทราบซึ่งส่งผลต่อการตรวจสอบความถูกต้องและทําให้การซิงค์ข้อมูลเมตาล่าช้า
การเผยแพร่สิทธิ์ล่าช้า: การเปลี่ยนแปลงสิทธิ์ไม่ได้เกิดขึ้นในทันที การสลับระหว่างโหมดความปลอดภัย (ข้อมูลประจําตัวผู้ใช้เทียบกับผู้รับมอบสิทธิ์) อาจต้องใช้เวลาในการเผยแพร่ก่อนที่จะมีผล แต่ควรใช้เวลาน้อยกว่า 1 นาที
การขึ้นกันของระนาบควบคุม: ไม่สามารถนําสิทธิ์ไปใช้กับผู้ใช้หรือกลุ่มที่ไม่มีอยู่ในระนาบควบคุมพื้นที่ทํางานได้ คุณต้องใช้ข้อมูลต้นฉบับร่วมกัน หรือผู้ใช้ต้องเป็นสมาชิกของบทบาทพื้นที่ทํางานของผู้ดู โปรดทราบว่ารหัสออบเจ็กต์เดียวกันทุกประการต้องอยู่ในทั้งสองตําแหน่ง กลุ่มและสมาชิกของกลุ่มนั้นจะไม่นับเป็นการจับคู่
การเข้าถึงที่อนุญาตมากที่สุดมีผลเหนือกว่า: เมื่อผู้ใช้อยู่ในหลายกลุ่มหรือหลายบทบาท จะได้รับการอนุญาตที่มีประสิทธิภาพมากที่สุด ตัวอย่าง: หากผู้ใช้มีทั้ง DENY ผ่านบทบาทหนึ่งและ GRANT ผ่านอีกบทบาทหนึ่ง GRANT จะมีความสําคัญเหนือกว่า
ข้อจํากัดของโหมดที่ได้รับมอบหมาย: ในโหมดที่ได้รับมอบหมาย การซิงค์ข้อมูลเมตาบนตารางทางลัดอาจล้มเหลวหากรายการต้นทางมีนโยบายความปลอดภัย OneLake ที่ไม่ให้สิทธิ์การเข้าถึงตารางแบบเต็มแก่เจ้าของรายการ
ลักษณะการทํางาน DENIAL: เมื่อหลายบทบาทนําไปใช้กับตารางทางลัดเดียว จุดตัดของสิทธิ์จะเป็นไปตามความหมายของ SQL Server: DENY แทนที่ GRANT สิ่งนี้สามารถสร้างผลลัพธ์การเข้าถึงที่ไม่คาดคิด
เงื่อนไขข้อผิดพลาดที่คาดไว้: ผู้ใช้อาจพบข้อผิดพลาดในสถานการณ์ต่างๆ เช่น:
เป้าหมายทางลัดเปลี่ยนชื่อหรือไม่ถูกต้อง
- ตัวอย่าง: หากแหล่งที่มาของตารางถูกลบ
การกําหนดค่า RLS (Row-Level Security) ผิดพลาด
นิพจน์บางอย่างสําหรับการกรอง RLS ไม่ได้รับการสนับสนุนใน OneLake และอาจอนุญาตให้เข้าถึงข้อมูลโดยไม่ได้รับอนุญาต
การวางคอลัมน์ที่ใช้ในนิพจน์ตัวกรองจะทําให้ RLS เป็นโมฆะ และการซิงค์ข้อมูลเมตาจะค้างจนกว่า RLS จะได้รับการแก้ไขบน OneLake Security Panel
สําหรับการแสดงตัวอย่างสาธารณะ เราสนับสนุนเฉพาะตารางนิพจน์เดียวเท่านั้น RLS แบบไดนามิกและ RLS หลายตารางไม่ได้รับการสนับสนุนในขณะนี้
ข้อจํากัดด้านความปลอดภัย (CLS) Column-Level
CLS ทํางานโดยรักษารายการคอลัมน์ที่อนุญาต ถ้าคอลัมน์ที่อนุญาตถูกลบออกหรือเปลี่ยนชื่อ นโยบาย CLS จะไม่ถูกต้อง
เมื่อ CLS ไม่ถูกต้อง การซิงค์ข้อมูลเมตาจะถูกบล็อกจนกว่ากฎ CLS จะได้รับการแก้ไขในแผงความปลอดภัยของ OneLake
ข้อมูลเมตาหรือการซิงค์สิทธิ์ล้มเหลว
- หากมีการเปลี่ยนแปลงในตาราง เช่น การเปลี่ยนชื่อคอลัมน์ ความปลอดภัยจะไม่ถูกจําลองแบบบนออบเจ็กต์ใหม่ และคุณได้รับข้อผิดพลาด UI ที่แสดงว่าไม่มีคอลัมน์
การเปลี่ยนชื่อตารางไม่รักษานโยบายความปลอดภัย: ถ้ามีการกําหนดบทบาท OneLake Security (OLS) ในระดับ Schema บทบาทเหล่านั้นจะยังคงมีผลตราบเท่าที่ชื่อตารางไม่เปลี่ยนแปลง การเปลี่ยนชื่อตารางจะทําลายการเชื่อมโยง และนโยบายความปลอดภัยจะไม่ถูกโยกย้ายโดยอัตโนมัติ ซึ่งอาจส่งผลให้เกิดการเปิดเผยข้อมูลโดยไม่ได้ตั้งใจจนกว่าจะใช้นโยบายอีกครั้ง
บทบาทความปลอดภัยของ OneLake ต้องไม่มีชื่อที่ยาวกว่า 124 อักขระ มิฉะนั้น การซิงค์ความปลอดภัยจะไม่สามารถซิงโครไนส์บทบาทได้
Security role ของ OneLake จะเผยแพร่บนตําแหน่งข้อมูลการวิเคราะห์ SQL ที่มีคํานําหน้า OLS_
การเปลี่ยนแปลงของผู้ใช้ในบทบาท OLS_ ไม่ได้รับการสนับสนุน และอาจทําให้เกิดลักษณะการทํางานที่ไม่คาดคิด
กลุ่มความปลอดภัยและรายชื่อการแจกจ่ายที่เปิดใช้งานจดหมายไม่ได้รับการสนับสนุน
เจ้าของเลคเฮาส์ต้องเป็นสมาชิกของบทบาทพื้นที่ทํางานของผู้ดูแลระบบ สมาชิก หรือผู้สนับสนุน มิฉะนั้น การรักษาความปลอดภัยจะไม่ถูกนําไปใช้กับตําแหน่งข้อมูลการวิเคราะห์ SQL
เจ้าของเลคเฮาส์ไม่สามารถเป็นบริการหลักสําหรับการซิงค์ความปลอดภัยในการทํางาน