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

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

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

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

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

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

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

เปรียบเทียบโหมดการเข้าถึง

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

เปลี่ยนโหมดการเข้าถึง OneLake

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

1. ไปที่ปลายทาง SQL analytics

2. ในประสบการณ์การใช้งานปลายทางการวิเคราะห์ SQL ให้เลือกแท็บ ความปลอดภัย

3. เลือก ดูการตั้งค่า>โหมดการเข้าถึงข้อมูล

   

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

   

5. เลือก ดําเนินการต่อ เพื่อยืนยันการเลือกของคุณ

โหมดข้อมูลประจําตัวผู้ใช้ในการรักษาความปลอดภัย 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 บนตารางจะถูกละเว้น

• ประสบการณ์ของ OneLake กําหนด RLS (ความปลอดภัยระดับแถว), CLS (ความปลอดภัยระดับคอลัมน์) และความปลอดภัยระดับวัตถุ

• อนุญาตสิทธิ์ 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 ที่มีอยู่หรือมีการสร้างบทบาทใหม่

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

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

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

เป็นผลให้:

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

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

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

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

ในโหมด ข้อมูลประจําตัวที่ได้รับมอบหมาย ตําแหน่งข้อมูลการวิเคราะห์ SQL จะรักษา ความเข้ากันได้ย้อนหลัง กับโมเดลความปลอดภัย SQL แบบดั้งเดิม คุณกําหนดและบังคับใช้ความปลอดภัยที่ ชั้นเอนจิน SQL และ บทบาทความปลอดภัยและนโยบายการเข้าถึงของ OneLake จะไม่ถูกนําไปใช้ กับการเข้าถึงระดับตาราง คุณต้องกําหนดการกรองและการควบคุมการเข้าถึงทั้งหมด — รวมถึงการเข้าถึงสคีมาและตาราง, ความปลอดภัยระดับแถว (RLS), ความปลอดภัยระดับคอลัมน์ (CLS) และการมาสกิ้งข้อมูลแบบไดนามิก (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 เช่น ความปลอดภัยระดับแถว (RLS) หรือความปลอดภัยระดับคอลัมน์ (CLS) จุดสิ้นสุดการวิเคราะห์ SQL จะบล็อกการเข้าถึงทางลัดนั้น

เป็นผลให้:

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

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

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

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

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

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

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

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

  หมายเหตุ

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

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

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

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

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

• ความปลอดภัยและทางลัดของ SQL ในคลังสินค้า: นโยบายความปลอดภัยที่กําหนดโดยใช้โครงสร้าง SQL ในคลังสินค้า เช่น ความปลอดภัยระดับแถว (RLS), ความปลอดภัยระดับคอลัมน์ (CLS) หรือความปลอดภัยระดับวัตถุ (OLS) จะถูกบังคับใช้เฉพาะในบริบทการทํางานของ SQL ของคลังข้อมูล (TDS endpoint) เท่านั้น

Limitations

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

  • ข้อยกเว้น:

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

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

    • RLS ในโหมดตัวตนผู้ใช้: เมื่อมีการกําหนดค่าความปลอดภัยระดับแถว (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 จะถูกบังคับใช้ทันทีและไม่ล่าช้าโดยการแคชโทเค็นที่เก็บข้อมูล

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

• ข้อจํากัดด้านความปลอดภัยระดับแถว (RLS):

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

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

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

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

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

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

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

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

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

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

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

• แนวทางปฏิบัติที่ดีที่สุดในการรักษาความปลอดภัยข้อมูลใน OneLake
• วิธีที่ความปลอดภัยของ OneLake ควบคุมการเข้าถึงข้อมูล