การรักษาความปลอดภัย OneLake สําหรับปลายทางการวิเคราะห์ SQL

ด้วยการรักษาความปลอดภัยของ OneLake ทําให้ Fabric ขยายวิธีที่องค์กรสามารถจัดการและบังคับใช้การเข้าถึงข้อมูลในปริมาณงานต่างๆ เฟรมเวิร์กการรักษาความปลอดภัยนี้ช่วยให้ผู้ดูแลระบบมีความยืดหยุ่นมากขึ้นในการกําหนดค่าสิทธิ์ ผู้ดูแลระบบสามารถเลือกระหว่าง การกํากับดูแลแบบรวมศูนย์ผ่าน OneLake หรือ การควบคุมแบบ SQL แบบละเอียด ภายในตําแหน่งข้อมูลการวิเคราะห์ SQL

โหมด Access ในตําแหน่งข้อมูลการวิเคราะห์ SQL

เมื่อใช้ตําแหน่งข้อมูลการวิเคราะห์ SQL โหมด access ที่เลือกจะกําหนดวิธีการบังคับใช้ความปลอดภัยของข้อมูล Fabric รองรับโมเดล access ที่แตกต่างกันสองแบบ โดยแต่ละรุ่นให้ประโยชน์ที่แตกต่างกันขึ้นอยู่กับความต้องการด้านการดําเนินงานและการปฏิบัติตามข้อกําหนดของคุณ:

  • โหมดข้อมูลประจําตัวของผู้ใช้: บังคับใช้การรักษาความปลอดภัยโดยใช้บทบาทและนโยบายของ OneLake ในโหมดนี้ ตําแหน่งข้อมูลการวิเคราะห์ SQL จะส่งข้อมูลประจําตัวของผู้ใช้ที่ลงชื่อเข้าใช้ไปยัง OneLake และการเข้าถึงการอ่านจะถูกควบคุมโดยกฎความปลอดภัยที่กําหนดไว้ภายใน OneLake ทั้งหมด สิทธิ์ระดับ SQL บนออบเจ็กต์ที่ไม่ใช่ข้อมูล (มุมมอง กระบวนงานที่เก็บไว้ ฟังก์ชัน) ได้รับการสนับสนุน เพื่อให้มั่นใจว่ามีการกํากับดูแลที่สอดคล้องกันในเครื่องมือต่างๆ เช่น Power BI, สมุดบันทึก และเลคเฮาส์

  • โหมดข้อมูลประจําตัวที่ได้รับมอบหมาย: ให้การควบคุมเต็มรูปแบบผ่าน SQL ในโหมดนี้ จุดสิ้นสุดการวิเคราะห์ SQL จะเชื่อมต่อกับ OneLake โดยใช้ข้อมูลประจําตัวของ พื้นที่ทํางานหรือเจ้าของรายการ และ ความปลอดภัยจะถูกควบคุมโดยสิทธิ์ SQL ที่กําหนดไว้ภายในฐานข้อมูลเท่านั้น โมเดลนี้รองรับแนวทางการรักษาความปลอดภัยแบบดั้งเดิม รวมถึง GRANT, REVOKE, บทบาทที่กําหนดเอง, Row-Level Security และ Dynamic Data Masking

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

สําคัญ

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

การเปรียบเทียบระหว่างโหมด 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 SQL หรือ REVOKE คําสั่งใดๆ

โหมดนี้ช่วยให้คุณสามารถจัดการความปลอดภัยจากส่วนกลาง เพื่อให้มั่นใจว่าการบังคับใช้ที่สอดคล้องกันในประสบการณ์ 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 และอยู่ภายใต้การควบคุมโดยบทบาทพื้นที่ทํางาน (ผู้ดูแลระบบ สมาชิก ผู้สนับสนุน)

สําหรับข้อมูลเพิ่มเติมเกี่ยวกับแบบจําลองสิทธิ์ที่มี โหมดข้อมูลประจําตัวของผู้ใช้ โปรดดู แบบจําลองการควบคุมการเข้าถึงข้อมูล สําหรับความปลอดภัยของ OneLake

การซิงค์ความปลอดภัยระหว่าง OneLake และปลายทางการวิเคราะห์ SQL

องค์ประกอบที่สําคัญของโหมดข้อมูลประจําตัวผู้ใช้คือบริการซิงค์ความปลอดภัย บริการเบื้องหลังนี้จะตรวจสอบการเปลี่ยนแปลงที่เกิดขึ้นกับบทบาทความปลอดภัยใน OneLake และทําให้แน่ใจว่าการเปลี่ยนแปลงเหล่านั้นจะสะท้อนให้เห็นในตําแหน่งข้อมูลการวิเคราะห์ SQL

บริการซิงค์ความปลอดภัยมีหน้าที่รับผิดชอบดังต่อไปนี้:

  • การตรวจจับการเปลี่ยนแปลงบทบาท OneLake รวมถึงบทบาทใหม่ การอัปเดต การกําหนดผู้ใช้ และการเปลี่ยนแปลงตาราง

  • การแปลนโยบายที่กําหนดโดย OneLake (RLS, CLS, OLS) เป็นโครงสร้างบทบาทฐานข้อมูลที่เข้ากันได้กับ SQL ที่เทียบเท่า

  • ตรวจสอบให้แน่ใจว่า ออบเจ็กต์ทางลัด (ตารางที่มาจากเลคเฮาส์อื่นๆ) ได้รับการตรวจสอบอย่างเหมาะสมเพื่อให้การตั้งค่าความปลอดภัย OneLake ดั้งเดิมได้รับการปฏิบัติตาม แม้ว่าจะเข้าถึงจากระยะไกลก็ตาม

การซิงโครไนซ์นี้ช่วยให้มั่นใจได้ว่าคําจํากัดความด้านความปลอดภัยของ OneLake ยังคงมีอํานาจ ทําให้ไม่จําเป็นต้องมีการแทรกแซงระดับ SQL ด้วยตนเองเพื่อจําลองพฤติกรรมความปลอดภัย เนื่องจากการรักษาความปลอดภัยถูกบังคับใช้จากส่วนกลาง:

  • คุณไม่สามารถกําหนด RLS, CLS หรือ OLS ได้โดยตรงโดยใช้ T-SQL ในโหมดนี้

  • คุณยังคงสามารถใช้สิทธิ์ SQL กับมุมมอง ฟังก์ชัน และกระบวนงานที่เก็บไว้โดยใช้ GRANT คําสั่ง or EXECUTE ได้

การลองย้อนกลับการซิงค์ความปลอดภัยอีกครั้ง

การซิงค์ความปลอดภัยมีกลไกการลองย้อนกลับอีกครั้งเพื่อปกป้องความเสถียรของระบบและหลีกเลี่ยงการใช้การประมวลผลที่ไม่จําเป็น:

  • ถ้าเกิดข้อผิดพลาดซ้ําๆ ขณะใช้ Security role ของ OneLake กับจุดสิ้นสุดการวิเคราะห์ SQL ระบบอาจหยุดความพยายามในการซิงโครไนส์อัตโนมัติชั่วคราว

  • การซิงโครไนส์จะดําเนินการต่อโดยอัตโนมัติเมื่อมีการแก้ไขบทบาทความปลอดภัย OneLake ที่มีอยู่หรือมีการสร้างบทบาทใหม่

ข้อผิดพลาดและการแก้ปัญหาการซิงค์ความปลอดภัย

สถานการณ์สมมติ ลักษณะการทํางานในโหมดข้อมูลประจําตัวผู้ใช้ ลักษณะการทํางานในโหมดที่ได้รับมอบหมาย การดําเนินการแก้ไข บันทึกย่อ
นโยบาย RLS อ้างอิงคอลัมน์ที่ถูกลบหรือเปลี่ยนชื่อ ข้อผิดพลาด: นโยบายความปลอดภัยระดับแถวอ้างอิงคอลัมน์ที่ไม่มีอยู่อีกต่อไป ฐานข้อมูลเข้าสู่สถานะข้อผิดพลาดจนกว่านโยบายจะได้รับการแก้ไข ข้อผิดพลาด: ชื่อ<คอลัมน์ชื่อ>คอลัมน์ไม่ถูกต้อง อัปเดตหรือลบบทบาทที่ได้รับผลกระทบอย่างน้อยหนึ่งบทบาท หรือคืนค่าคอลัมน์ที่ขาดหายไป การอัปเดตต้องทําในเลคเฮาส์ที่สร้างบทบาท
นโยบาย CLS อ้างอิงคอลัมน์ที่ถูกลบหรือเปลี่ยนชื่อ ข้อผิดพลาด: นโยบายความปลอดภัยระดับคอลัมน์อ้างอิงคอลัมน์ที่ไม่มีอยู่อีกต่อไป ฐานข้อมูลเข้าสู่สถานะข้อผิดพลาดจนกว่านโยบายจะได้รับการแก้ไข ข้อผิดพลาด: ชื่อ<คอลัมน์ชื่อ>คอลัมน์ไม่ถูกต้อง อัปเดตหรือลบบทบาทที่ได้รับผลกระทบอย่างน้อยหนึ่งบทบาท หรือคืนค่าคอลัมน์ที่ขาดหายไป การอัปเดตต้องทําในเลคเฮาส์ที่สร้างบทบาท
นโยบาย RLS/CLS อ้างอิงตารางที่ถูกลบหรือเปลี่ยนชื่อ ข้อผิดพลาด: นโยบายความปลอดภัยอ้างอิงตารางที่ไม่มีอยู่อีกต่อไป ไม่มีข้อผิดพลาดปรากฏขึ้น แบบสอบถามล้มเหลวอย่างเงียบ ๆ หากตารางหายไป อัปเดตหรือลบบทบาทที่ได้รับผลกระทบอย่างน้อยหนึ่งบทบาท หรือกู้คืนตารางที่ขาดหายไป การอัปเดตต้องทําในเลคเฮาส์ที่สร้างบทบาท
นโยบาย DDM (การมาสก์ข้อมูลแบบไดนามิก) อ้างอิงคอลัมน์ที่ถูกลบหรือเปลี่ยนชื่อ DDM ไม่รองรับจากการรักษาความปลอดภัยของ OneLake ต้องดําเนินการผ่าน SQL ข้อผิดพลาด: ชื่อ<คอลัมน์ชื่อ>คอลัมน์ไม่ถูกต้อง อัปเดตหรือลบกฎ DDM ที่ได้รับผลกระทบอย่างน้อยหนึ่งข้อ หรือคืนค่าคอลัมน์ที่หายไป อัปเดตนโยบาย DDM ในตําแหน่งข้อมูลการวิเคราะห์ SQL
ข้อผิดพลาดของระบบ (ความล้มเหลวที่ไม่คาดคิด) ข้อผิดพลาด: เกิดข้อผิดพลาดของระบบที่ไม่คาดคิด ลองอีกครั้งหรือติดต่อฝ่ายสนับสนุน ข้อผิดพลาด: มี ข้อผิดพลาดภายในเกิดขึ้นขณะนําการเปลี่ยนแปลงตารางไปใช้กับ SQL ลองดําเนินการอีกครั้ง หากปัญหายังคงอยู่ โปรดติดต่อฝ่ายสนับสนุนของ ฝ่ายสนับสนุนของ Microsoft ไม่มี
ไม่รองรับผู้ใช้หลัก ข้อผิดพลาด: ไม่รองรับผู้ใช้หลัก ข้อผิดพลาด: ไม่รองรับผู้ใช้หลัก ลบผู้ใช้{username}ออกจากบทบาทDefaultReader ข้อผิดพลาดนี้เกิดขึ้นหากผู้ใช้ไม่ใช่ Entra ID ที่ถูกต้องอีกต่อไป (ตัวอย่างเช่น ผู้ใช้ออกจากองค์กรหรือถูกลบ) ลบออกจากบทบาทเพื่อแก้ไขข้อผิดพลาด

ลักษณะการทํางานของทางลัดที่มีการซิงค์ความปลอดภัย

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

เป็นผลให้:

  • ผู้ใช้ต้องมี access ที่ถูกต้องใน ทั้งคู่ทางลัด source (ปลายทาง Lakehouse หรือ SQL Analytics ปัจจุบัน) และdestination ที่ข้อมูลอยู่จริง

  • หากผู้ใช้ไม่มีสิทธิ์ในด้านใดด้านหนึ่ง คิวรีจะล้มเหลว โดยมีข้อผิดพลาดในการเข้าถึง

การออกแบบนี้ช่วยรักษาความสมบูรณ์ของความปลอดภัยข้ามขอบเขตของบ้านพักในทะเลสาบ พร้อมลดความจําเป็นในการกําหนดตัวตนซ้ําซ้อนระหว่างสินค้าผู้ผลิตและผู้บริโภค

โหมดที่ได้รับมอบหมายในการรักษาความปลอดภัย OneLake

ในโหมด ข้อมูลประจําตัวที่ได้รับมอบหมาย ตําแหน่งข้อมูลการวิเคราะห์ SQL จะรักษา ความเข้ากันได้ย้อนหลัง กับโมเดลความปลอดภัย SQL แบบดั้งเดิม มีการกําหนดและบังคับใช้ความปลอดภัยที่ เลเยอร์กลไกจัดการ SQL และ บทบาทความปลอดภัยและนโยบายการเข้าถึงของ OneLake จะไม่ถูกส่งต่อ ไปยังการเข้าถึงระดับตาราง การกรองและการควบคุมการเข้าถึงทั้งหมด รวมถึงการเข้าถึง Schema และตาราง Row-Level Security (RLS), Column-Level Security (CLS) และ Dynamic Data Masking (DDM) ต้องกําหนดโดยใช้โครงสร้าง SQL (GRANT/REVOKEนโยบายความปลอดภัย และอื่นๆ)

กฎความปลอดภัยใดๆ ที่กําหนดไว้ใน OneLake (ตัวอย่างเช่น กฎที่บังคับใช้โดย Spark หรือกลไกจัดการอื่นๆ ที่อ่านผ่าน OneLake ) จะไม่นําไปใช้ เมื่อมีการคิวรีข้อมูลเดียวกันผ่านปลายทางการวิเคราะห์ SQL เลือกโหมดนี้เมื่อปริมาณงานขึ้นอยู่กับความหมายด้านความปลอดภัยของ SQL หรือเมื่อเครื่องมือ T-SQL ที่มีอยู่ต้องการความเข้ากันได้อย่างสมบูรณ์

เมื่อผู้ใช้เชื่อมต่อกับตําแหน่งข้อมูลการวิเคราะห์ SQL และออกคิวรี:

  • SQL ตรวจสอบความถูกต้องของคิวรีกับสิทธิ์ที่กําหนดไว้ที่เลเยอร์ SQL

  • หากคิวรีได้รับอนุญาต ระบบจะดําเนินการ access ข้อมูลที่จัดเก็บไว้ใน OneLake

  • การเข้าถึงข้อมูลนี้ดําเนินการโดยใช้ ข้อมูลประจําตัวของเจ้าของตําแหน่งข้อมูลการวิเคราะห์ Lakehouse หรือ SQL หรือที่เรียกว่า บัญชีรายการ ไม่ใช่ผู้ใช้ที่ลงชื่อเข้าใช้

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

โหมดนี้รองรับเครื่องมือและแนวทางปฏิบัติ T-SQL ที่มีอยู่ที่ใช้โดย DBA หรือแอปพลิเคชัน โดยมีความเข้ากันได้อย่างสมบูรณ์สําหรับ SQL GRANT/REVOKE ในทุกระดับอ็อบเจ็กต์และ RLS, CLS และ DDM ที่กําหนดโดย SQL

ลักษณะการทํางานของทางลัดในโหมดที่ได้รับมอบหมาย

เนื่องจากโหมดที่ได้รับมอบหมายเชื่อมต่อกับ OneLake โดยใช้ข้อมูลประจําตัวของเจ้าของรายการ ทางลัดจะทํางานเฉพาะเมื่อเจ้าของมีสิทธิ์เข้าถึงตารางต้นทางทั้งหมดอย่างไม่จํากัด หากตารางต้นทางมีกฎความปลอดภัยระดับ OneLake ที่ใช้ เช่น Row-Level Security (RLS), Column-Level Security (CLS) ปลายทางการวิเคราะห์ SQL จะบล็อกการเข้าถึงทางลัดนั้น

เป็นผลให้:

  • ทางลัดที่ชี้ไปยังตารางต้นทางที่ไม่มี กฎความปลอดภัยระดับข้อมูล จะทํางานได้ตามปกติในโหมดที่ได้รับมอบหมาย

  • ทางลัดที่ชี้ไปยังตารางต้นทางที่มี RLS หรือ CLS ในการรักษาความปลอดภัย OneLake บนผู้ผลิตไม่ สามารถเข้าถึง ได้ผ่านจุดสิ้นสุดการวิเคราะห์ SQL ในโหมดที่ได้รับมอบหมาย แม้ว่าผู้ใช้ปลายทางจะมีสิทธิ์ SQL บนวัตถุทางลัดก็ตาม

  • เมื่อต้องการใช้ทางลัดที่มีแหล่งที่มามีนโยบายความปลอดภัย OneLake ให้ใช้ โหมดข้อมูลประจําตัวของผู้ใช้ ที่ปลายทางของผู้บริโภค เพื่อให้ข้อมูลประจําตัวของผู้ใช้ปลายทางได้รับการประเมินเทียบกับกฎความปลอดภัย OneLake ของแหล่งที่มา

วิธีเปลี่ยนโหมด OneLake access

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

  1. นําทางไปยังพื้นที่ทํางาน Fabric ของคุณและเปิดเลคเฮาส์ของคุณ จากมุมบนขวา ให้เปลี่ยนจากเลคเฮาส์เป็นตําแหน่งข้อมูลการวิเคราะห์ SQL

  2. จากการนําทางด้านบน ให้ไปที่แท็บ ความปลอดภัย และเลือกโหมดการเข้าถึง OneLake อย่างใดอย่างหนึ่งต่อไปนี้:

    • ข้อมูลประจําตัวของผู้ใช้ – ใช้ข้อมูลประจําตัวของผู้ใช้ที่ลงชื่อเข้าใช้ บังคับใช้บทบาท OneLake

    • ข้อมูลประจําตัวที่ได้รับมอบหมาย – ใช้ข้อมูลประจําตัวของเจ้าของรายการ บังคับใช้เฉพาะสิทธิ์ SQL เท่านั้น

  3. ป๊อปอัปจะเปิดขึ้นเพื่อยืนยันการเลือกของคุณ เลือก ใช่ เพื่อยืนยันการเปลี่ยนแปลง

สําคัญ

การเปลี่ยนโหมดความปลอดภัยชั่วคราวทําให้ตําแหน่งข้อมูลการวิเคราะห์ SQL ไม่พร้อมใช้งานในพื้นที่ทํางานทั้งหมด การดําเนินการนี้จะยกเลิกคิวรีที่ทํางานอยู่และคิวทั้งหมดที่ปลายทางการวิเคราะห์ SQL ทั้งหมดในพื้นที่ทํางานนั้น เปลี่ยนโหมดเฉพาะเมื่อจําเป็น และควรเปลี่ยนในช่วงนอกเวลาทําการเพื่อหลีกเลี่ยงการหยุดทํางาน

ข้อควรพิจารณาเมื่อสลับระหว่างโหมดต่างๆ

สําคัญ

การสลับระหว่างข้อมูลประจําตัวผู้ใช้และโหมดที่ได้รับมอบหมาย (ในทิศทางใดทิศทางหนึ่ง) จะลบออบเจ็กต์ข้อมูลเมตาแบบอินไลน์ รวมถึงฟังก์ชันที่มีค่าตาราง (TVF) และฟังก์ชันที่มีค่าสเกลาร์ ลักษณะการทํางานนี้มีผลกับคําจํากัดความของข้อมูลเมตาเท่านั้น ข้อมูลพื้นฐานใน OneLake จะไม่ได้รับผลกระทบ

การเปลี่ยนเป็นโหมดข้อมูลประจําตัวผู้ใช้

  • สิทธิ์ SQL RLS, CLS และระดับตารางจะถูกละเว้น

  • ต้องกําหนดค่าบทบาท OneLake สําหรับผู้ใช้เพื่อรักษา access

  • เฉพาะผู้ใช้ที่มีสิทธิ์ Viewer หรือการเข้าถึงแบบอ่านอย่างเดียวที่ใช้ร่วมกันเท่านั้นที่ควบคุมโดยความปลอดภัยของ OneLake

  • บทบาท SQL ที่มีอยู่จะถูกลบและไม่สามารถกู้คืนได้

การเปลี่ยนไปใช้โหมดข้อมูลประจําตัวที่ได้รับมอบหมาย

  • บทบาทและนโยบายความปลอดภัยของ OneLake จะไม่ถูกนําไปใช้อีกต่อไป

  • บทบาท SQL และนโยบายความปลอดภัยจะเปิดใช้งาน

  • เจ้าของรายการต้องมี OneLake access ที่ถูกต้อง มิฉะนั้น คิวรีทั้งหมดอาจล้มเหลว

หมาย เหตุ

  • ออบเจ็กต์ SQL ไม่สืบทอดความเป็นเจ้าของ: ทางลัดทําหน้าที่เป็นตารางในจุดสิ้นสุดการวิเคราะห์ SQL แต่จงใจเบี่ยงเบนไปจากการเชื่อมโยงความเป็นเจ้าของ SQL มาตรฐานเพื่อรักษาเสถียรภาพการรักษาความปลอดภัยแบบครบวงจร

    • กฎการไม่สืบทอด: วัตถุ SQL ที่ได้รับ (มุมมอง กระบวนงานที่เก็บไว้ หรือฟังก์ชัน) จะไม่สืบทอดสิทธิ์จากเจ้าของอ็อบเจ็กต์

    • การตรวจสอบความถูกต้องของรันไทม์: สิทธิ์ได้รับการตรวจสอบกับข้อมูลประจําตัวของผู้โทรในเวลาดําเนินการ เพื่อให้มั่นใจว่านามธรรมของ SQL ไม่สามารถหลีกเลี่ยงนโยบายระดับ OneLake ได้

  • การพึ่งพาระนาบควบคุมและการประเมินตัวตนที่มีประสิทธิภาพ: ผู้ใช้ต้องมีสิทธิ์ Fabric artifact ที่จําเป็นก่อนที่จะเชื่อมต่อกับปลายทางการวิเคราะห์ SQL การอนุญาตข้อมูลจะประเมินผู้ใช้ที่ลงชื่อเข้าใช้และสมาชิกที่แท้จริงของผู้ใช้ในกลุ่ม Microsoft Entra ที่รองรับ เทียบกับนโยบายความปลอดภัยของ OneLake ที่ต้นทาง

  • พฤติกรรมการประเมินสิทธิ์: การประเมินสิทธิ์จะแตกต่างกันไปตามชนิดของตารางตามรูปแบบการบังคับใช้ปัจจุบัน

    • ตารางทางลัด: การเข้าถึงอาจถูกปฏิเสธเมื่อไม่เป็นไปตามเงื่อนไขการอนุญาตที่จําเป็น นี่เป็นผลการบังคับใช้ที่เข้มงวด ไม่ใช่ความสามารถ DENY ตามบทบาทในการรักษาความปลอดภัย OneLake

    • กฎทั่วไป: เมื่อการบังคับใช้ไม่สามารถตรวจสอบการเข้าถึงได้อย่างชัดเจน

  • การออกแบบColumn-Level Security (CLS): CLS รักษารายการคอลัมน์ที่อนุญาตอย่างเข้มงวด

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

    • การป้องกันการซิงค์: เมื่อนโยบายไม่ถูกต้อง การซิงค์ข้อมูลเมตาจะถูกบล็อกโดยการออกแบบจนกว่ากฎจะได้รับการแก้ไขในแผงความปลอดภัยของ OneLake

    • การตรวจสอบความถูกต้องของสคีมา: การเปลี่ยนชื่อคอลัมน์โดยไม่อัปเดตนโยบายความปลอดภัยจะทริกเกอร์ข้อผิดพลาดของ UI ที่ระบุว่าคอลัมน์ "ไม่มีอยู่จริง" จนกว่าการกําหนดค่าจะซิงโครไนซ์

    หมายเหตุ

    ในตําแหน่งข้อมูลการวิเคราะห์ SQL การรักษาความปลอดภัย OneLake จะถูกบังคับใช้สําหรับการเข้าถึงข้อมูล ในขณะที่ข้อมูลเมตาของ Schema ยังคงเป็นไปตามพฤติกรรมของกลไกจัดการ SQL ผู้ใช้อาจเห็นคอลัมน์ใน Object Explorer หรือsys.columnsแม้กระทั่งเมื่อ Column-Level Security ป้องกันไม่ให้อ่านคอลัมน์เหล่านั้น ลักษณะการทำงานนี้เป็นไปตามที่คาดและออกแบบไว้

  • การเผยแพร่และการซิงโครไนส์บทบาท (SLA):

    • การซิงค์ความปลอดภัย OneLake: เมื่อ Security role ของ OneLake เปลี่ยนแปลงในโหมดข้อมูลประจําตัวของผู้ใช้ การอัปเดตจะไม่เกิดขึ้นทันที แม้ว่าโดยปกติแล้วจะเร็ว แต่อาจใช้เวลาถึง 5 นาที ในการซิงโครไนซ์กับตําแหน่งข้อมูลการวิเคราะห์ SQL

    • คํานําหน้าอัตโนมัติ: Security role ของ OneLake จะถูกเผยแพร่ไปยังตําแหน่งข้อมูลการวิเคราะห์ SQL ด้วยOLS_คํานําหน้า

    • ลําดับความสําคัญของการซิงค์: กระบวนการซิงค์ความปลอดภัยจะรีเฟรชสถานะของ OLS_ บทบาทเป็นระยะ การเปลี่ยนแปลงด้วยตนเองในบทบาทเหล่านี้ไม่ได้รับการสนับสนุน และจะถูกเขียนทับในระหว่างรอบการซิงค์ถัดไป ถ้าไม่มีการเปลี่ยนแปลงในการซิงค์ การซิงค์ความปลอดภัยจะไม่แทนที่การเปลี่ยนแปลงด้วยตนเอง

สําคัญ

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

Limitations

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

    • ข้อยกเว้น:

      • พฤติกรรมการปฏิเสธทางลัด: สําหรับตารางที่มีการสนับสนุนทางลัด การบังคับใช้ยังคงสามารถปฏิเสธการเข้าถึงผู้ดูแลระบบ สมาชิก หรือผู้มีส่วนร่วมได้ในบางกรณี

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

      • RLS ในโหมดข้อมูลประจําตัวของผู้ใช้: เมื่อมีการกําหนดค่าความปลอดภัย Row-Level (RLS) ในโหมดข้อมูลประจําตัวของผู้ใช้ ระบบจะบังคับใช้กฎความปลอดภัยที่กําหนดไว้สําหรับผู้ใช้ทั้งหมด รวมถึงผู้ที่อยู่ในบทบาทผู้ดูแลระบบ สมาชิก และผู้สนับสนุน

  • การมองเห็น Schema ในข้อมูลเมตาของออบเจ็กต์: จุดสิ้นสุดการวิเคราะห์ SQL จะส่งคืน ชื่อ Schema ทั้งหมดใน เมตาดาต้าของออบเจ็กต์เสมอ โดยไม่คํานึงถึงสิทธิ์ระดับตารางของผู้ใช้ ตารางที่ผู้ใช้ไม่มีสิทธิ์จะถูกกรองออกและไม่ปรากฏในรายการ

    • ด้วยเหตุนี้ ผู้ใช้อาจเห็น Schema ที่ไม่มีตารางที่มองเห็นได้ในตัวสํารวจวัตถุหรือใน INFORMATION_SCHEMA/sys แบบสอบถามแค็ตตาล็อก

  • การพึ่งพาการซิงโครไนซ์ความปลอดภัย: ในโหมดตัวตนผู้ใช้ กระบวนการซิงค์ความปลอดภัยจะซิงโครไนซ์บทบาทความปลอดภัยของ OneLake ไปยังปลายทางการวิเคราะห์ SQL จนกว่าการซิงโครไนซ์จะเสร็จสิ้น SQL อาจประเมินการเข้าถึงชั่วคราวโดยใช้สถานะสิทธิ์ SQL ที่มีอยู่สําหรับตารางทั้งหมด รวมถึงตารางทางลัดจากรายการอื่น ๆ เมื่อการซิงโครไนส์เสร็จสิ้น ตําแหน่งข้อมูล SQL จะสะท้อนถึงการกําหนดค่าความปลอดภัย OneLake

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

  • เวลาหยุดทํางานของการตรวจสอบความถูกต้องของเป้าหมาย: เมื่อเป้าหมายทางลัดเปลี่ยนไป (ตัวอย่างเช่น เปลี่ยนชื่อหรืออัปเดต URL) ฐานข้อมูลจะเข้าสู่ โหมดผู้ใช้คนเดียว ชั่วครู่ในขณะที่ระบบตรวจสอบความถูกต้องของเป้าหมายใหม่ ในช่วงเวลานี้ คิวรีจะถูกบล็อก โดยทั่วไปการดําเนินการเหล่านี้จะรวดเร็ว แต่อาจใช้เวลาถึง 5 นาทีในการซิงโครไนซ์ ทั้งนี้ขึ้นอยู่กับกระบวนการภายใน

    • การสร้างทางลัดสคีมาอาจทําให้เกิดข้อผิดพลาดที่ทราบซึ่งส่งผลต่อการตรวจสอบความถูกต้องและทําให้การซิงค์ข้อมูลเมตาล่าช้า

  • การแคชโทเค็นโหมดที่ได้รับมอบหมาย: ในโหมดที่ได้รับมอบหมาย ตําแหน่งข้อมูลการวิเคราะห์ SQL จะแคชโทเค็นการเข้าถึงที่เก็บข้อมูลที่ใช้ในการดึงข้อมูลจาก OneLake ในนามของข้อมูลประจําตัวของเจ้าของ หาก สิทธิ์ของเจ้าของมีการเปลี่ยนแปลง โทเค็นที่ออกก่อนหน้านี้อาจยังคงใช้ได้จนกว่าจะหมดอายุ ด้วยเหตุนี้ การเปลี่ยนแปลงการเข้าถึงที่เชื่อมโยงกับข้อมูลประจําตัวของเจ้าของอาจไม่มีผลทันที และสามารถคงอยู่ได้จนกว่าโทเค็นจะหมดอายุ ซึ่งโดยทั่วไปจะไม่เกิน 30-60 นาที

  • การเปลี่ยนแปลงนโยบาย GRANT/DENY ความปลอดภัยของ OneLake จะถูกบังคับใช้ทันทีและไม่ล่าช้าโดยการแคชโทเค็นที่เก็บข้อมูล

  • การยกเลิกคิวรีที่ใช้งานอยู่: เพื่อรักษาความสมบูรณ์และความปลอดภัยของข้อมูล คิวรีที่ใช้งานอยู่อาจถูกยกเลิกโดยอัตโนมัติหากการกําหนดค่าทางลัดเปลี่ยนแปลงระหว่างการดําเนินการ

  • ข้อจํากัดด้านความปลอดภัยRow-Level (RLS):

    • รองรับเฉพาะตารางนิพจน์เดียวเท่านั้น RLS แบบไดนามิกและ RLS หลายตารางไม่พร้อมใช้งาน

    • การวางคอลัมน์ที่ใช้ในนิพจน์ตัวกรองจะหยุดการซิงโครไนส์เมตาดาต้าจนกว่า RLS จะได้รับการแก้ไขในแผงความปลอดภัย OneLake

  • ความซับซ้อนของบทบาทและการซิงค์ข้อมูลเมตา: ความซับซ้อนสูงในบทบาทความปลอดภัย โดยเฉพาะอย่างยิ่งบทบาทที่เกี่ยวข้องกับจุดตัดจํานวนมากและความหมายของสหภาพที่ใช้ RLS อาจทําให้การซิงค์ความปลอดภัยล้มเหลว การซิงค์ความปลอดภัยที่ล้มเหลวจะป้องกันไม่ให้มีการใช้นโยบายความปลอดภัย และบล็อกความสามารถในการซิงโครไนซ์ข้อมูลเมตา

  • ข้อจํากัดของสคีมาและบทบาท:

    • การเปลี่ยนชื่อ: Security role ของ OneLake เชื่อมโยงกับชื่อตาราง การเปลี่ยนชื่อตารางจะทําลายการเชื่อมโยง และนโยบายจะไม่ย้ายโดยอัตโนมัติ ซึ่งอาจส่งผลให้เกิดการเปิดเผยข้อมูลโดยไม่ได้ตั้งใจจนกว่าจะใช้นโยบายอีกครั้ง

    • ขีดจํากัดอักขระ: ชื่อบทบาทความปลอดภัยของ OneLake ต้องไม่เกิน 124 อักขระ มิฉะนั้น การสร้างบทบาทหรือการซิงโครไนซ์จะล้มเหลวบนตําแหน่งข้อมูลการวิเคราะห์ SQL

    • OLS_ การปรับเปลี่ยนบทบาท: ไม่รองรับการเปลี่ยนแปลงของผู้ใช้ใน OLS_ บทบาทและอาจทําให้เกิดพฤติกรรมที่ไม่คาดคิด

  • ข้อมูลประจําตัวที่ไม่รองรับ: กลุ่มความปลอดภัยที่เปิดใช้งานจดหมายและรายชื่อการแจกจ่ายไม่ได้รับการสนับสนุนในขณะนี้

  • ข้อกําหนดของเจ้าของเลคเฮาส์:

    • เจ้าของเลคเฮาส์ต้องเป็นสมาชิกของบทบาทพื้นที่ทํางานผู้ดูแลระบบ สมาชิก หรือผู้สนับสนุน มิฉะนั้น การรักษาความปลอดภัยจะไม่ถูกนําไปใช้กับตําแหน่งข้อมูลการวิเคราะห์ SQL

เนื้อหาที่เกี่ยวข้อง

  • Last updated on