หมายเหตุ
การเข้าถึงหน้านี้ต้องได้รับการอนุญาต คุณสามารถลอง ลงชื่อเข้าใช้หรือเปลี่ยนไดเรกทอรีได้
การเข้าถึงหน้านี้ต้องได้รับการอนุญาต คุณสามารถลองเปลี่ยนไดเรกทอรีได้
ความปลอดภัยของ OneLake เป็นระบบที่แบ่งตามบทบาท ซึ่งกําหนดว่าใครสามารถเข้าถึงข้อมูลใน OneLake และสามารถดําเนินการอะไรกับข้อมูลนั้นได้ การเข้าใจโมเดลการควบคุมการเข้าถึงข้อมูลช่วยให้คุณมอบสิทธิ์เฉพาะการเข้าถึงที่จําเป็นแก่ผู้ใช้ เพื่อให้คุณสามารถปกป้องข้อมูลที่ละเอียดอ่อนได้ ในขณะที่ยังคงให้คนที่เหมาะสมทํางานกับข้อมูลนั้น
บทความนี้อธิบายโครงสร้างบทบาทความปลอดภัยของ OneLake วิธีการผสานรวมกับสิทธิ์พื้นที่ทํางานและรายการ วิธีที่ OneLake ใช้และแก้ไขการเข้าถึงข้อมูลของคุณ และข้อจํากัดที่ควรคํานึงถึง
บทบาทความปลอดภัยของ OneLake
ความปลอดภัยของ OneLake ใช้โมเดลการควบคุมการเข้าถึงตามบทบาท (RBAC) ในการจัดการการเข้าถึงข้อมูลใน OneLake ในประสบการณ์ความปลอดภัยของ OneLake แต่ละบทบาทจะมีองค์ประกอบดังต่อไปนี้:
- สิทธิ์ :สิทธิ์ที่บทบาทมอบให้กับข้อมูล เช่น Read หรือ ReadWrite
- ประเภท: ประเภทบทบาท ความปลอดภัยของ OneLake รองรับเฉพาะบทบาท Grant ซึ่งให้สมาชิกเข้าถึงข้อมูลในบทบาทนั้นได้ มันไม่รองรับบทบาท Deny ที่ตัดสิทธิ์การเข้าถึง
- ข้อมูลในบทบาท: ตาราง โฟลเดอร์ หรือสคีมาที่บทบาทอนุญาตให้เข้าถึง คุณยังสามารถกําหนดการเข้าถึงข้อมูลด้วยความปลอดภัยระดับแถวและระดับคอลัมน์บนตารางได้อีกด้วย
- สมาชิกในบทบาท:ตัวตน Microsoft Entra ที่กําหนดให้กับบทบาท เช่น ผู้ใช้ กลุ่ม หรือตัวตนที่ไม่ใช่ผู้ใช้ หากคุณกําหนดกลุ่ม Microsoft Entra ความปลอดภัยของ OneLake จะมอบบทบาทนี้ให้กับสมาชิกทุกคนของกลุ่ม
ความปลอดภัยของ OneLake ใช้โมเดลปฏิเสธโดยค่าเริ่มต้น ดังนั้นผู้ใช้จะเริ่มต้นโดยไม่มีสิทธิ์เข้าถึงข้อมูล เว้นแต่บทบาทความปลอดภัยของ OneLake จะอนุญาตอย่างชัดเจน บางรายการใน Fabric เริ่มต้นด้วยบทบาทเริ่มต้นที่ให้ผู้ใช้เข้าถึงพื้นฐานตามสิทธิ์ในพื้นที่ทํางาน
สิทธิ์และรายการที่รองรับ
บทบาทความปลอดภัยของ OneLake รองรับสิทธิ์ดังต่อไปนี้:
-
อ่าน: ให้ผู้ใช้สามารถอ่านข้อมูลจากตารางและดูข้อมูลเมตาของตารางและคอลัมน์ที่เกี่ยวข้อง ในแง่ของ SQL สิทธิ์นี้เทียบเท่ากับทั้ง
VIEW_DEFINITIONและSELECTสําหรับข้อมูลเพิ่มเติม โปรดดูที่ ความปลอดภัยของเมตาดาต้า -
ReadWrite: ให้ผู้ใช้สามารถอ่านและเขียนข้อมูลในตารางหรือโฟลเดอร์ และดูข้อมูลเมตาของตารางและคอลัมน์ที่เกี่ยวข้องได้ ในแง่ของ SQL สิทธิ์นี้เทียบเท่ากับ
ALTER,DROP,UPDATE, และINSERT. สําหรับข้อมูลเพิ่มเติม ดูที่ สิทธิ์ ReadWrite
คุณสามารถสร้างบทบาทความปลอดภัยของ OneLake สําหรับรายการ Fabric ต่อไปนี้:
| รายการผ้า | สิทธิ์ที่รองรับ |
|---|---|
| Lakehouse | อ่าน อ่านเขียน |
| Azure Databricks mirrored catalog | Read |
| ฐานข้อมูลมิเรอร์ | Read |
| แคตตาล็อกแบบมิเรอร์ | Read |
สิทธิ์ ReadWrite
ใช้สิทธิ์ ReadWrite เพื่อให้ผู้ใช้แบบอ่านอย่างเดียวสามารถเขียนข้อมูลเฉพาะในรายการได้
ReadWrite ใช้ได้เฉพาะกับผู้ใช้ที่มีสิทธิ์อ่านในรายการ เช่น ผู้ใช้ที่มีบทบาท Viewer workspace การกําหนด ReadWrite ให้กับผู้ดูแลระบบ สมาชิก หรือผู้ร่วมเขียนในพื้นที่ทํางานจะไม่มีผลเนื่องจากบทบาทในพื้นที่ทํางานเหล่านี้มีสิทธิ์เขียนอยู่แล้ว
ReadWrite รวมสิทธิ์ทั้งหมดที่ได้รับจากสิทธิ์ Read และยังให้สิทธิ์การเขียนกับวัตถุที่เลือกและเนื้อหาของมันด้วย ตัวอย่างเช่น สิทธิ์ ReadWrite บนโฟลเดอร์จะให้สิทธิ์เขียนทั้งโฟลเดอร์และข้อมูลภายในโฟลเดอร์นั้น
ผู้ใช้ที่มีสิทธิ์ ReadWrite สามารถดําเนินการดังต่อไปนี้:
- สร้าง ลบ หรือเปลี่ยนชื่อโฟลเดอร์หรือตาราง
- อัปโหลดหรือแก้ไขไฟล์
- สร้าง ลบ หรือเปลี่ยนชื่อทางลัด
ผู้ใช้สามารถเขียนผ่านสมุดบันทึก Spark, ตัวสํารวจไฟล์ OneLake หรือ API ของ OneLake เนื่องจาก Fabric รองรับการเขียนข้อมูลด้วยเอนจินเดียวเท่านั้น ผู้ใช้ที่มีสิทธิ์ ReadWrite จึงสามารถเขียนข้อมูลนั้นได้เฉพาะผ่าน OneLake เท่านั้น เครื่องมือค้นหาทั้งหมดยังคงบังคับใช้การอ่านอย่างสม่ําเสมอ
บทบาทความปลอดภัยของ OneLake ที่ให้สิทธิ์ ReadWrite ไม่สามารถมีข้อจํากัดด้านความปลอดภัยระดับแถว (RLS) หรือระดับคอลัมน์ (CLS) ได้
ความปลอดภัยของ OneLake และสิทธิ์พื้นที่ทํางาน
บทบาท Workspace เป็นขอบเขตความปลอดภัยแรกสําหรับข้อมูลใน OneLake พวกเขาจัดการระนาบควบคุม — สร้างและจัดการรายการและสิทธิ์ใน Fabric — และนําไปใช้กับทุกรายการในพื้นที่ทํางาน สําหรับสิทธิ์เฉพาะของ OneLake ที่แต่ละบทบาทในพื้นที่ทํางานให้ ดูที่ การให้สิทธิ์การเข้าถึงกับบทบาทพื้นที่ทํางาน หากต้องการเรียนรู้เพิ่มเติมเกี่ยวกับบทบาทในพื้นที่ทํางาน ดูที่ บทบาทในพื้นที่ทํางานใน Fabric
นอกเหนือจากการเข้าถึงในแผงควบคุมแล้ว บทบาทในพื้นที่ทํางานยังสามารถให้การเข้าถึงข้อมูลผ่านบทบาทความปลอดภัยเริ่มต้นของ OneLake ได้อีกด้วย (บทบาทเริ่มต้นจะใช้เฉพาะกับผู้ดูเท่านั้น เนื่องจากบทบาทผู้ดูแลระบบ สมาชิก และผู้ร่วมเขียนมีสิทธิ์สูงขึ้นผ่านสิทธิ์การเขียน)บทบาทเริ่มต้นคือบทบาทความปลอดภัย OneLake ปกติที่ Fabric สร้างโดยอัตโนมัติทุกรายการใหม่ โดยให้สิทธิ์ในพื้นที่ทํางานหรือรายการบางอย่างแก่ผู้ใช้ระดับการเข้าถึงข้อมูลในรายการนั้นตามค่าเริ่มต้น ตัวอย่างเช่น รายการเลคเฮาส์มีบทบาท DefaultReader ที่ช่วยให้ผู้ใช้ที่มีสิทธิ์ ReadAll ดูข้อมูลในเลคเฮาส์ การเข้าถึงเริ่มต้นนี้ช่วยให้ผู้ใช้ที่ทํางานกับรายการที่สร้างใหม่มีระดับการเข้าถึงพื้นฐาน บทบาทเริ่มต้นทั้งหมดใช้ฟีเจอร์การจําลองเสมือนของสมาชิก เพื่อให้สมาชิกของบทบาทเป็นผู้ใช้ใดก็ได้ในพื้นที่ทํางานนั้นที่มีสิทธิ์ตามที่กําหนด ตัวอย่างเช่น ผู้ใช้ทั้งหมดที่มีสิทธิ์ ReadAll ในเลคเฮาส์
ตารางต่อไปนี้แสดงบทบาทมาตรฐานเริ่มต้น รายการอาจมีบทบาทเริ่มต้นเฉพาะที่ใช้กับประเภทรายการนั้นเท่านั้น
| รายการผ้า | ชื่อบทบาท | อนุญาตแล้ว | สมาชิกที่ได้รับมอบหมาย |
|---|---|---|---|
| Lakehouse | DefaultReader |
Read | ผู้ใช้ทั้งหมดที่มีสิทธิ์ ReadAll |
| Azure Databricks mirrored catalog | DefaultReader |
Read | ผู้ใช้ทุกคนที่มีสิทธิ์อ่าน |
| แคตตาล็อกแบบมิเรอร์ | DefaultReader |
Read | ผู้ใช้ทุกคนที่มีสิทธิ์อ่าน |
| ฐานข้อมูลที่มิเรอร์ | DefaultReader |
Read | ผู้ใช้ทั้งหมดที่มีสิทธิ์ ReadAll |
คุณสามารถแก้ไขหรือลบบทบาทเริ่มต้นจากรายการ Fabric เพื่อเปลี่ยนสิทธิ์การเข้าถึงของผู้ใช้ในกลุ่มสมาชิกนั้น
การเข้าถึงข้อมูลของเครื่องยนต์และผู้ใช้
ความปลอดภัยของ OneLake จะตั้งค่าเริ่มต้นเป็นการเข้าถึงที่มีสิทธิพิเศษน้อยที่สุด บางการดําเนินการในระดับจัดเก็บข้อมูลไม่สามารถบังคับใช้ RLS หรือ CLS ได้ ดังนั้นเมื่อคําสั่งค้นหาไม่สามารถกรองได้อย่างปลอดภัย OneLake จะบล็อกคําสั่งนั้นทั้งหมดแทนที่จะเสี่ยงเปิดเผยข้อมูลที่ผู้ใช้ไม่ได้รับอนุญาตให้เห็น การที่คิวรีจะถูกกรองหรือบล็อกขึ้นอยู่กับเส้นทางการเข้าถึง - เครื่องมือค้นหาที่รองรับ หรือการเข้าถึงโดยตรงจากผู้ใช้
สําหรับเอนจินที่รองรับการกรอง RLS และ CLS และข้อกําหนดของแต่ละประเภท ดูที่ การอ่านข้อมูลที่ปลอดภัยด้วย OneLake security
ขอบเขตและการบังคับใช้
ส่วนนี้ให้รายละเอียดเกี่ยวกับวิธีที่บทบาทความปลอดภัย OneLake ให้สิทธิ์การเข้าถึงขอบเขตเฉพาะวิธีการทํางานของการเข้าถึงและวิธีแก้ไขการเข้าถึงในหลายบทบาทและประเภทการเข้าถึง
ความปลอดภัยระดับโต๊ะ
OneLake แทนตารางทั้งหมดในรูปแบบโฟลเดอร์ แต่จากมุมมองของความปลอดภัยของ OneLake และเครื่องมือค้นหาใน Fabric ไม่ใช่ทุกโฟลเดอร์จะเป็นตาราง เพื่อให้เป็นตารางที่ถูกต้อง โฟลเดอร์ต้องเป็นไปตามเงื่อนไขดังต่อไปนี้:
- โฟลเดอร์นี้อยู่ในไดเรกทอรี
Tables/ของรายการ สําหรับรายการที่เปิดใช้งาน Schema โฟลเดอร์ต้องอยู่ในโฟลเดอร์ Schema ที่ถูกต้องด้วย - โฟลเดอร์นี้จะมี
_delta_logโฟลเดอร์ที่มีไฟล์ JSON ที่เกี่ยวข้องสําหรับเมตาดาต้าของตาราง - โฟลเดอร์นี้ไม่มีทางลัดลูก
หากคุณกําหนดค่า RLS หรือ CLS บนตาราง OneLake จะปฏิเสธการเข้าถึงเมื่อโฟลเดอร์ของตารางไม่ตรงตามเกณฑ์เหล่านี้ หากไม่มี RLS หรือ CLS OneLake จะถือว่าโฟลเดอร์ที่ไม่ตรงตามเกณฑ์เหล่านี้เป็นโฟลเดอร์และใช้ความปลอดภัยระดับโฟลเดอร์
ความปลอดภัยระดับแถวและระดับคอลัมน์
ภายในบทบาท คุณสามารถจํากัดการเข้าถึงแถวและคอลัมน์เฉพาะของตารางโดยใช้ความปลอดภัยระดับแถวและระดับคอลัมน์ สําหรับข้อมูลเพิ่มเติมเกี่ยวกับสิ่งที่แต่ละคอนโทรลทําและวิธีที่ OneLake บังคับใช้ ดูที่ ความปลอดภัยระดับตาราง คอลัมน์ และแถวใน OneLake สําหรับข้อมูลเกี่ยวกับวิธีที่ RLS และ CLS แก้ไขเมื่อผู้ใช้อยู่ในหลายบทบาท ดูที่ การประเมินบทบาทความปลอดภัยหลายบทบาทของ OneLake
ความปลอดภัยของข้อมูลเมตา
สิทธิ์การอ่านของความปลอดภัยของ OneLake ให้สิทธิ์การเข้าถึงข้อมูลและข้อมูลเมตาในตารางอย่างเต็มรูปแบบ สําหรับผู้ใช้ที่ไม่มีสิทธิ์เข้าถึงตาราง ข้อมูลจะไม่ถูกเปิดเผย กฎนี้ยังใช้กับความปลอดภัยระดับคอลัมน์และความสามารถของผู้ใช้ในการเห็นหรือไม่เห็นคอลัมน์ในตารางนั้น อย่างไรก็ตาม ความปลอดภัยของ OneLake ไม่ได้รับประกันว่าข้อมูลเมตาของตารางจะไม่สามารถเข้าถึงได้ ข้อความแสดงข้อผิดพลาดและประสบการณ์บางอย่างอาจแสดงชื่อคอลัมน์
การสืบทอดสิทธิ์โฟลเดอร์และการผ่าน
สิทธิ์โฟลเดอร์มีผลต่อลําดับชั้นในสองทิศทาง:
- การสืบทอด: สิทธิ์ที่ได้รับในโฟลเดอร์จะมีผลกับไฟล์และโฟลเดอร์ย่อยของโฟลเดอร์นั้น
- การเดินหน้าและรายการ: เมื่อผู้ใช้มีสิทธิ์ในรายการลูก ความปลอดภัยของ OneLake จะช่วยให้พวกเขาสามารถแสดงรายการและเดินดูโฟลเดอร์แม่เพื่อให้สามารถค้นหาและนําทางไปยังข้อมูลที่เข้าถึงได้ การทราเวอร์สัลไม่อนุญาตให้เข้าถึงไฟล์หรือโฟลเดอร์ของพี่น้อง
ลองพิจารณาลําดับชั้นของบ้านริมทะเลสาบใน OneLake ดังนี้:
Tables/
──── (empty folder)
Files/
────folder1
│ │ file11.txt
│ │
│ └───subfolder11
│ │ file111.txt
│ │
│ └───subfolder111
│ │ file1111.txt
│
└───folder2
│ file21.txt
คุณสร้างบทบาท Role1, , ที่ให้สิทธิ์ อ่าน บน subfolder11. ผ่านการสืบทอด สมาชิกในบทบาทนั้นสามารถอ่านfile111.txtและทุกอย่างในsubfolder111 สมาชิกสามารถดูและเดินไปfolder1ถึงsubfolder11ได้ แต่พวกเขามองไม่เห็นfile11.txtเพราะเป็นพี่น้องของ subfolder11 และพวกเขามองไม่เห็นTablesเพราะเป็นพี่น้องของFiles
Files/
│
└───folder1
│ │
│ └───subfolder11 <-- READ
│ │ file111.txt
│ │
│ └───subfolder111
│ │ file1111.txt
คุณสร้างบทบาทอีกตัวหนึ่ง Role2ที่ให้สิทธิ์ อ่าน บน folder2. ผ่านการสืบทอด สมาชิกสามารถอ่าน file21.txt. สมาชิกสามารถเดินทางfolder2Filesไปถึงมันได้ แต่พวกเขาไม่สามารถมองเห็นfolder1หรือแม้แต่ลูก ๆ ของมันได้
Files/
│
└───folder2 <-- READ
│ file21.txt
สําหรับทางลัด พฤติกรรมจะต่างออกไปเล็กน้อย ทางลัดไปยังแหล่งข้อมูลภายนอกทํางานเหมือนกับโฟลเดอร์ อย่างไรก็ตาม ทางลัดไปยังสถานที่อื่น ๆ ใน OneLake จะมีพฤติกรรมเฉพาะ สิทธิ์เป้าหมายของปุ่มลัดจะกําหนดการเข้าถึงทางลัด OneLake เมื่อแสดงทางลัด OneLake จะไม่โทรตรวจสอบการเข้าถึงเป้าหมาย ดังนั้น เมื่อคุณแสดงรายการไดเรกทอรี OneLake จะคืนทางลัดภายในทั้งหมดไม่ว่าจะเข้าถึงเป้าหมายของคุณหรือไม่ การตรวจสอบการเข้าถึงจะประเมินเมื่อคุณพยายามเปิดทางลัด และคุณจะเห็นเฉพาะข้อมูลที่คุณมีสิทธิ์ที่จําเป็นในการดูเท่านั้น
Shortcuts
ความปลอดภัยของ OneLake ผสานรวมกับทางลัดเพื่อรักษาความปลอดภัยข้อมูลทั้งภายในและภายนอก OneLake ทางลัดใช้หนึ่งในสองโหมดการตรวจสอบสิทธิ์:
- การส่งผ่าน: ทางลัดใช้ข้อมูลตัวตนของผู้ใช้ที่ค้นหาเพื่อเข้าถึงเป้าหมาย Passthrough เป็นค่าเริ่มต้นสําหรับทางลัด OneLake ไป OneLake
- มอบหมาย: ทางลัดจะใช้ตัวตนการเชื่อมต่อหรือข้อมูลรับรองที่กําหนดค่าไว้เพื่อเข้าถึงเป้าหมาย ทางลัด OneLake-to-OneLake สามารถใช้การตรวจสอบสิทธิ์แบบมอบหมาย และทางลัดไปยังระบบภายนอกจะใช้การตรวจสอบสิทธิ์แบบมอบหมายเสมอ
การสร้างทางลัดต้องมีสิทธิ์ทั้งในเส้นทางที่สร้างทางลัดและเส้นทางเป้าหมาย สําหรับข้อกําหนดในการสร้างและเข้าถึงคีย์ลัดแต่ละประเภท ดูที่ ความปลอดภัยคีย์ลัด OneLake
การรักษาความปลอดภัย OneLake ในทางลัดแบบพาสทรู
เมื่อผู้ใช้เข้าถึงข้อมูลผ่าน ทางลัด passthrough OneLake ไปยัง OneLake OneLake OneLake จะใช้ตัวตนของผู้ใช้ที่โทรเพื่ออนุญาตการเข้าถึงเส้นทางเป้าหมาย การเข้าถึงที่มีประสิทธิภาพของผู้ใช้ถูกจํากัดโดยสิทธิ์ของพวกเขาทั้งในเส้นทางลัดและเส้นทางเป้าหมาย
Note
การระบุตัวตนของเครื่องมือค้นหาและการตรวจสอบสิทธิ์ทางลัดเป็นการตั้งค่าแยกกัน ทางลัดแบบ passthrough โดยปกติจะใช้ตัวตนของผู้ใช้ที่โทรเพื่อเข้าถึงเป้าหมาย อย่างไรก็ตาม โมเดลเชิงความหมายของ Power BI ที่ใช้ Direct Lake over SQL และ SQL analytics endpoints ในโหมดระบุตัวตนที่ได้รับมอบหมายจะใช้ตัวตนเจ้าของของสินค้าผู้บริโภคหรือแหล่งข้อมูล พฤติกรรมนี้จะไม่เปลี่ยนโหมดการตรวจสอบสิทธิ์ที่ตั้งค่าไว้ของทางลัด สําหรับการส่งผ่านตัวตนผู้ใช้แบบ end-to-end ให้ใช้ Direct Lake แทน OneLake หรือกําหนดค่า SQL analytics endpoint ให้ใช้โหมดการเข้าถึงตัวตนของผู้ใช้
คุณไม่สามารถกําหนดสิทธิ์ความปลอดภัยของ OneLake โดยตรงบนทางลัด OneLake-to-OneLake ได้ สิทธิ์ในโฟลเดอร์ที่มีทางลัดจะรวมกับสิทธิ์บนเส้นทางเป้าหมาย หากรายการเป้าหมายรองรับความปลอดภัยของ OneLake ผู้ใช้จําเป็นต้องเข้าถึงผ่านบทบาทความปลอดภัยของ OneLake หากรายการเป้าหมายไม่รองรับความปลอดภัยของ OneLake ผู้ใช้จําเป็นต้องมีสิทธิ์ Fabric ReadAll บนรายการเป้าหมาย ผู้ใช้ไม่จําเป็นต้องมีสิทธิ์ Fabric Read บนไอเท็มเป้าหมายเพียงเพื่อเข้าถึงข้อมูลผ่านทางลัดเท่านั้น
การรักษาความปลอดภัย OneLake ในทางลัดที่ได้รับมอบหมาย
ทางลัดที่ได้รับมอบหมายจะใช้ตัวตนหรือข้อมูลรับรองที่กําหนดค่าไว้แทนตัวตนของผู้ใช้ที่โทรเพื่อเข้าถึงเป้าหมาย ความปลอดภัยของ OneLake จํากัดสิ่งที่ผู้ใช้ที่โทรสามารถเข้าถึงผ่านการเชื่อมต่อนั้น
ทางลัด OneLake ที่ได้รับมอบหมาย
สําหรับทางลัด OneLake ที่มอบหมายให้ ผู้ใช้ที่โทรจะเห็นจุดตัดของการเข้าถึงบนเส้นทางลัด และการเข้าถึงของตัวตนการเชื่อมต่อที่กําหนดค่าไว้บนเส้นทางเป้าหมาย รองรับความปลอดภัยระดับคอลัมน์ (CLS) ทั้งสองเส้นทาง รองรับความปลอดภัยระดับแถว (RLS) บนเส้นทางเป้าหมาย แต่คุณไม่สามารถกําหนด RLS บนเส้นทางทางลัดได้
ทางลัดภายนอกที่ได้รับมอบหมาย
ทางลัดไปยังระบบภายนอก เช่น ADLS, Amazon S3 และ Dataverse จะใช้ข้อมูลรับรองการเชื่อมต่อที่กําหนดค่าไว้เพื่อเข้าถึงแหล่งภายนอก ความปลอดภัยของ OneLake จะถูกนํามาใช้บนการเข้าถึงที่ได้รับจากข้อมูลรับรองนั้น
ตัวอย่างเช่น สมมติว่า user1 สร้างทางลัด lakehouse ไปยังโฟลเดอร์ในถัง Amazon S3 และ user2 เข้าถึงทางลัดจาก lakehouse User2 สามารถเข้าถึงข้อมูล S3 ได้ก็ต่อเมื่อข้อมูลรับรองการเชื่อมต่อ S3 ที่กําหนดค่าไว้สามารถเข้าถึงต้นทางได้ และความปลอดภัยของ OneLake อนุญาตให้ผู้ใช้ 2 เข้าถึงเส้นทางทางลัด
คุณสามารถให้สิทธิ์การเข้าถึงความปลอดภัยของ OneLake สําหรับทางลัดภายนอกทั้งหมดหรือเส้นทางย่อยที่เลือก สิทธิ์ในโฟลเดอร์จะสืบทอดแบบวนซ้ําไปยังโฟลเดอร์ย่อยทั้งหมด รวมถึงโฟลเดอร์ภายในทางลัด ผู้ใช้ที่เข้าถึงทางลัดภายนอกผ่านทางลัด OneLake อื่นต้องยังได้รับอนุญาตจากความปลอดภัย OneLake ที่ใช้กับทางลัดภายนอกเดิม
การเข้าถึงทางลัดภายนอกผ่าน Spark หรือการเรียก OneLake API โดยตรงยังต้องได้รับสิทธิ์ Fabric Read บนรายการที่มีทางลัดภายนอกด้วย สิทธิ์นี้จําเป็นสําหรับการแก้ไขปัญหาการเชื่อมต่อกับระบบภายนอกอย่างปลอดภัย
ประเมินบทบาทความปลอดภัยหลายบทบาทของ OneLake
ผู้ใช้สามารถเป็นสมาชิกในบทบาทความปลอดภัยของ OneLake หลายบทบาทได้ OneLake รวมสิทธิ์การเข้าถึงที่ได้รับจากบทบาทเหล่านั้นเป็น บทบาทที่มีประสิทธิภาพ ซึ่งจะกําหนดข้อมูลที่ผู้ใช้สามารถเข้าถึงได้ OneLake ประเมินบทบาทที่มีประสิทธิภาพเป็นขั้นตอน
แก้ไขการเข้าถึงภายในแต่ละบทบาท
OneLake จะจัดการแต่ละบทบาทอย่างอิสระก่อน ภายในบทบาท ผู้ใช้สามารถเข้าถึงข้อมูลที่ได้รับอนุญาตโดยองค์ประกอบความปลอดภัยทั้งสามอย่างเท่านั้น:
- ความปลอดภัยระดับวัตถุ (OLS) กําหนดว่าบทบาทสามารถเข้าถึงตารางหรือโฟลเดอร์ใดได้
- ความปลอดภัยระดับแถว (RLS) จํากัดว่าบทบาทจะเข้าถึงแถวใดของตารางที่กําหนดได้
- ความปลอดภัยระดับคอลัมน์ (CLS) จํากัดว่าบทบาทสามารถเข้าถึงคอลัมน์ใดในตารางที่กําหนดได้
เนื่องจากทั้งสามองค์ประกอบนี้ใช้ได้ OneLake จึงเลือกจุดตัดของทั้งสอง ตัวอย่างเช่น หาก Role1 อนุญาตให้เข้าถึง Table1 และจํากัดแถวและคอลัมน์ การเข้าถึงที่แก้ไขสําหรับ Role1 คือ:
Role1 = R1_OLS ∩ R1_RLS ∩ R1_CLS
สัญลักษณ์จุดตัด (∩) หมายความว่าผู้ใช้จะได้รับสิทธิ์เข้าถึงเฉพาะที่อนุญาตโดย OLS, RLS และ CLS ในบทบาทนั้นเท่านั้น
รวมการเข้าถึงข้ามบทบาท
หลังจากแก้ไขแต่ละบทบาทแล้ว OneLake จะรวมบทบาทโดยใช้โมเดลแบบสหภาพ หรือโมเดลที่มีข้อจํากัดน้อยที่สุด สัญลักษณ์สหภาพ (∪) หมายความว่าการเข้าถึงที่ได้รับจากบทบาทใด ๆ จะกลายเป็นส่วนหนึ่งของบทบาทที่มีผลบังคับใช้ หาก Role1 ให้สิทธิ์เข้าถึง TableA และ Role2 ให้สิทธิ์เข้าถึง TableB ผู้ใช้ที่อยู่ในทั้งสองบทบาทสามารถเข้าถึงทั้งสองตารางได้
สําหรับสองบทบาท บทบาทที่มีประสิทธิผลคือ:
Effective role = Role1 ∪ Role2
เมื่อหลายบทบาทอนุญาตให้เข้าถึงตารางเดียวกัน กฎความปลอดภัยระดับแถวจะรวมกับ OR โอเปอเรเตอร์ ตัวอย่างเช่น พรีดิเคตที่อนุญาตcity = 'Redmond'และcity = 'New York'รวมกันเป็นcity = 'Redmond' OR city = 'New York'
กฎความปลอดภัยระดับคอลัมน์ก็รวมกันเป็นสหภาพเช่นกัน ยกเว้นในจุดสิ้นสุดการวิเคราะห์ SQL ในปลายทาง SQL analytics CLS ใช้การปฏิเสธความหมายที่เข้มงวดกว่า หากบทบาทใดซ่อนคอลัมน์ จุดสิ้นสุดจะบล็อกการเข้าถึงคอลัมน์นั้น ดังนั้น endpoint จะตัดกับรายการอนุญาตของ CLS ข้ามบทบาททั้งหมดของผู้ใช้ แทนที่จะรวมกันเป็นสหภาพ
Important
ให้กฎ RLS และ CLS ที่ต้องใช้ร่วมกันในบทบาทเดียวกัน OneLake ไม่รองรับการรวมบทบาทที่บทบาทสองบทบาทอนุญาตให้มีชุดคอลัมน์ที่แตกต่างกันสําหรับตาราง และบทบาทใดบทบาทหนึ่งก็ใช้ RLS กับตารางนั้นด้วย ตัวอย่างเช่น ผู้ใช้ไม่สามารถเป็นสมาชิกของ Role1 ซึ่งอนุญาตให้มีคอลัมน์ c1 และ c2 และบางส่วนของแถว และ Role2 ซึ่งอนุญาตให้ใช้คอลัมน์ c2 และ c3
รวมทางลัดและการเข้าถึงเป้าหมายเข้าด้วยกัน
สําหรับทางลัด OneLake จะประเมินบทบาทที่ตําแหน่งทางลัดและที่เป้าหมายทางลัดแยกกัน บทบาทเป้าหมายจะกลายเป็น บทบาทที่สรุป ได้ที่ตําแหน่งทางลัด OneLake จะตัดกับการเข้าถึงรวมจากบทบาททางลัดกับการเข้าถึงรวมจากบทบาทเป้าหมายที่อนุมาน ขั้นตอนนี้ป้องกันไม่ให้การเข้าถึงที่สืบทอดที่ตําแหน่งทางลัดมีอิทธิพลต่อข้อจํากัดของเป้าหมาย
สําหรับบทบาททางลัดสองบทบาทและบทบาทเป้าหมายที่อนุมานได้สองบทบาท การเข้าถึงที่มีประสิทธิภาพคือ:
Effective shortcut access = (ShortcutRole1 ∪ ShortcutRole2) ∩ (InferredRole1 ∪ InferredRole2)
ในนิพจน์ ShortcutRole1 นี้ และ ShortcutRole2 เป็นบทบาทที่ตําแหน่งทางลัด
InferredRole1 และ InferredRole2 คือบทบาทที่อนุมานได้จากเป้าหมายทางลัด แต่ละบทบาทจะถูกแก้ไขจากส่วนประกอบ OLS, RLS และ CLS ก่อนที่ OneLake จะรวมบทบาทเหล่านี้เข้าด้วยกัน
ข้อจํากัดด้านความปลอดภัยของ OneLake
ถ้าคุณกําหนดบทบาทความปลอดภัย OneLake ให้กับผู้ใช้ที่เป็นผู้เยี่ยมชม B2B คุณต้อง กําหนดค่าการตั้งค่าการทํางานร่วมกันภายนอกของคุณสําหรับ B2B ใน Microsoft Entra External ID ตั้งค่าการเข้าถึงผู้ใช้ Guest เป็น ผู้ใช้ Guest มีสิทธิ์เข้าถึงเท่ากับสมาชิก (ครอบคลุมมากที่สุด)
ถ้าคุณเพิ่มรายชื่อการแจกจ่ายให้กับบทบาทในความปลอดภัยของ OneLake จุดสิ้นสุดการวิเคราะห์ SQL จะไม่สามารถแก้ไขสมาชิกของรายการเพื่อบังคับใช้การเข้าถึงได้ ดังนั้น ผู้ใช้จึงดูเหมือนไม่ได้เป็นสมาชิกของบทบาทเมื่อเข้าถึงปลายทางการวิเคราะห์ SQL Direct Lake บน SQL semantic models ก็มีข้อจํากัดนี้เช่นกัน
โน้ตบุ๊ก Spark ต้องการสภาพแวดล้อมให้เป็น 3.5 หรือสูงกว่า และใช้ Fabric runtime 1.3
บ้านทะเลสาบที่ไม่ใช่สคีมาไม่รองรับการดูตัวอย่างข้อมูลสําหรับตารางที่ปลอดภัย RLS และ CLS ใช้บ้านริมทะเลสาบที่รองรับสคีมาพร้อมความปลอดภัย OneLake
ความปลอดภัยของ OneLake ไม่ทํางานร่วมกับ Azure Data Share หรือ Purview Data Share สําหรับข้อมูลเพิ่มเติม โปรดดู Azure Data Share
ตารางต่อไปนี้แสดงข้อจํากัดของบทบาทความปลอดภัย OneLake
Scenario Limit จํานวนสูงสุดของบทบาทความปลอดภัย OneLake ต่อ Fabric Item 250 บทบาทต่อรายการ (ดูหมายเหตุ) จํานวนสูงสุดของสมาชิกต่อบทบาทความปลอดภัย OneLake ผู้ใช้หรือกลุ่มผู้ใช้ 500 คนต่อบทบาท จํานวนสูงสุดของสิทธิ์ต่อบทบาทความปลอดภัย OneLake 500 สิทธิ์ต่อบทบาท Note
คุณสามารถขอเพิ่มบทบาทต่อรายการเป็น 1,000 รายการได้ หากต้องการขอเพิ่มจํานวนเงิน กรุณาติดต่อฝ่ายสนับสนุนของ Azure
ความล่าช้า
การเปลี่ยนแปลงข้อกําหนดบทบาทใช้เวลาประมาณ 5 นาทีในการใช้งาน
การเปลี่ยนแปลงไปยังกลุ่มผู้ใช้ในบทบาทความปลอดภัย OneLake ใช้เวลาประมาณหนึ่งชั่วโมงสําหรับ OneLake เพื่อใช้สิทธิ์ของบทบาทในกลุ่มผู้ใช้ที่อัปเดตแล้ว เอ็นจิ้น Fabric บางตัวมีเลเยอร์แคชของตัวเอง ดังนั้นอาจต้องใช้เวลาเพิ่มอีกหนึ่งชั่วโมงในการอัปเดตการเข้าถึงในทุกระบบ