วิธีที่ความปลอดภัยของ OneLake ควบคุมการเข้าถึงข้อมูล

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