Model kontrol akses keamanan OneLake

Dokumen ini menyediakan panduan terperinci tentang cara kerja model kontrol akses keamanan OneLake. Ini berisi detail tentang bagaimana peran disusun, bagaimana peran tersebut berlaku untuk data, dan apa integrasinya dengan struktur lain dalam Fabric.

Peran keamanan OneLake

Keamanan OneLake menggunakan model kontrol akses berbasis peran (RBAC) untuk mengelola akses ke data di OneLake. Setiap peran terdiri dari beberapa komponen utama.

  • Jenis: Apakah peran memberikan akses (GRANT) atau menghapus akses (DENY). Hanya peran jenis GRANT yang didukung.
  • Izin: Tindakan atau tindakan tertentu yang diberikan atau ditolak.
  • Ruang lingkup: Objek OneLake yang memiliki izin. Objek adalah tabel, folder, atau skema.
  • Anggota: Identitas Microsoft Entra apa pun yang ditetapkan ke peran, seperti pengguna, grup, atau identitas nonpengguna. Peran diberikan kepada semua anggota grup Microsoft Entra.

Dengan menetapkan anggota ke peranan, pengguna tersebut kemudian tunduk pada cakupan izin yang terkait dengan peran tersebut. Karena keamanan OneLake menggunakan model penolakan secara default, semua pengguna mulai tidak memiliki akses data, kecuali jika secara eksplisit diberikan oleh peran keamanan OneLake.

Izin dan item yang didukung

Peran keamanan OneLake mendukung izin berikut:

  • Membaca: Memberi pengguna kemampuan untuk membaca data dari tabel dan melihat metadata tabel dan kolom terkait. Dalam istilah SQL, izin ini setara dengan VIEW_DEFINITION dan SELECT. Untuk informasi selengkapnya, lihat Keamanan metadata.
  • ReadWrite: Memberi pengguna kemampuan untuk membaca dan menulis data dari tabel atau folder dan melihat metadata tabel dan kolom terkait. Dalam istilah SQL, izin ini setara dengan ALTER, DROP, UPDATE, dan INSERT. Untuk informasi selengkapnya, lihat Izin ReadWrite.

Keamanan OneLake memungkinkan pengguna untuk menentukan peran akses data hanya untuk item Fabric berikut.

Barang Kain Izin yang didukung
Lakehouse Baca, BacaTulis
Katalog tercermin Azure Databricks Baca
Database yang direplikasi Baca
Katalog yang dicerminkan Baca

Izin keamanan dan ruang kerja OneLake

Izin ruang kerja adalah batas keamanan pertama untuk data dalam OneLake. Setiap ruang kerja mewakili satu domain atau area proyek tempat tim dapat berkolaborasi pada data. Anda mengelola keamanan di ruang kerja melalui peran dalam Fabric workspace. Pelajari selengkapnya tentang kontrol akses berbasis peran Fabric (RBAC): Peran ruang kerja

Peran ruang kerja Fabric memberikan izin yang berlaku untuk semua item di ruang kerja. Tabel berikut menguraikan izin dasar yang diizinkan oleh peran ruang kerja.

Izin Admin Anggota Kontributor Penampil
Menampilkan file di OneLake Selalu* Ya Selalu* Ya Selalu* Ya Tidak, secara bawaan. Gunakan keamanan OneLake untuk memberikan akses.
Menulis file di OneLake Selalu* Ya Selalu* Ya Selalu* Ya Tidak, secara bawaan. Gunakan keamanan OneLake untuk memberikan akses.
Dapat mengedit peran keamanan OneLake Selalu* Ya Selalu* Ya Tidak Tidak

*Karena peran Admin Ruang Kerja, Anggota, dan Kontributor secara otomatis memberikan izin Tulis ke OneLake, mereka menggantikan izin Baca keamanan OneLake apa pun.

Peran ruang kerja mengatur akses data control plane, yaitu interaksi terkait pembuatan dan pengelolaan item Fabric serta izin. Selain itu, peran ruang kerja juga menyediakan tingkat akses default ke item data dengan menggunakan peran default keamanan OneLake. (Perhatikan bahwa peran default hanya berlaku untuk Pemirsa, karena Admin, Anggota, dan Kontributor telah meningkatkan akses melalui izin Tulis) Peran default adalah peran keamanan OneLake normal yang dibuat secara otomatis dengan setiap item baru. Ini memberi pengguna izin ruang kerja atau item tertentu tingkat akses default ke data dalam item tersebut. Misalnya, item lakehouse memiliki peran DefaultReader yang memungkinkan pengguna yang memiliki izin ReadAll untuk melihat data di lakehouse. Ini memastikan bahwa pengguna yang mengakses item yang baru dibuat memiliki tingkat akses dasar. Semua peran default menggunakan fitur virtualisasi anggota, sehingga anggota peran adalah pengguna apa pun di ruang kerja tersebut dengan izin yang diperlukan. Misalnya, semua pengguna dengan izin ReadAll di lakehouse. Tabel berikut ini memperlihatkan apa peran default standarnya. Item mungkin memiliki peran default khusus yang hanya berlaku untuk jenis item tersebut.

Barang Kain Nama peran Izin Folder yang disertakan Anggota yang ditetapkan
Lakehouse DefaultReader Baca Semua folder di bawah Tables/ dan Files/ Semua pengguna dengan izin ReadAll
Lakehouse DefaultReadWriter Baca Semua folder Semua pengguna dengan izin Tulis
Katalog Cermin Azure Databricks DefaultReader Baca Semua folder di bawah Tables/ dan Files/ Semua pengguna dengan izin Baca
Database Cermin DefaultReader Baca Semua folder di bawah Tables/ dan Files/ Semua pengguna dengan izin ReadAll

Catatan

Untuk membatasi akses ke pengguna tertentu atau folder tertentu, ubah peran default atau hapus dan buat peran kustom baru.

Keamanan OneLake dan izin item

Dalam ruang kerja, item Fabric dapat dikonfigurasi izinnya secara terpisah dengan peran dalam ruang kerja. Anda dapat mengonfigurasi izin baik melalui berbagi item atau dengan mengelola izin item. Izin berikut menentukan kemampuan pengguna untuk melakukan tindakan pada item di Fabric. Untuk informasi selengkapnya tentang berbagi item, lihat Cara kerja berbagi Lakehouse

Izin Dapat melihat file di OneLake? Dapatkah menulis file di OneLake? Dapatkah membaca data melalui titik akhir analitik SQL?
Baca Tidak, secara bawaan. Gunakan keamanan OneLake untuk memberikan akses. Tidak Tidak
BacaSemua Ya, melalui fungsi DefaultReader. Gunakan keamanan OneLake untuk membatasi akses. Tidak Tidak*
Tulis Ya Ya Ya
Jalankan, Bagikan Ulang, Lihat Output, Lihat Log N/A - tidak dapat diberikan sendiri N/A - tidak dapat diberikan sendiri N/A - tidak dapat diberikan sendiri

*Tergantung pada mode titik akhir analitik SQL.

Buat peran

Anda dapat menentukan dan mengelola peran keamanan OneLake melalui UX manajemen peran keamanan OneLake item Anda.

Pelajari selengkapnya di Mulai menggunakan peran akses data.

Akses mesin dan pengguna ke data

Akses data ke OneLake terjadi dengan salah satu dari dua cara:

  • Melalui mesin kueri, termasuk mesin Fabric dan mesin pihak ketiga resmi
  • Melalui akses oleh pengguna (permintaan dari mesin eksternal tanpa otorisasi dianggap sebagai akses oleh pengguna)

Keamanan OneLake memastikan bahwa data selalu aman. Karena fitur keamanan OneLake tertentu seperti keamanan tingkat baris dan kolom tidak didukung oleh operasi tingkat penyimpanan, tidak semua jenis akses ke data aman tingkat baris atau kolom dapat diizinkan. Ini menjamin bahwa pengguna tidak dapat melihat baris atau kolom yang tidak diizinkan. Mesin Fabric diaktifkan agar dapat menerapkan pemfilteran keamanan pada tingkat baris dan kolom pada kueri data. Ini berarti ketika pengguna mengkueri data di lakehouse atau item lain yang memiliki RLS keamanan OneLake atau CLS, hasil yang dilihat pengguna tidak menampilkan baris dan kolom tersembunyi. Untuk akses pengguna ke data di OneLake dengan RLS atau CLS di dalamnya, kueri diblokir jika pengguna yang meminta akses tidak diizinkan untuk melihat semua baris atau kolom dalam tabel tersebut.

Tabel di bawah ini menguraikan mesin mana yang mendukung pemfilteran RLS dan CLS.

Mesin Pemfilteran RLS/CLS Keadaan
Lakehouse Ya GA
Buku catatan Spark Ya GA
Titik Akhir Analitik SQL dalam mode akses identitas pengguna Ya GA
Model semantik menggunakan Direct Lake pada mode OneLake Ya GA
Eventhouse Hanya RLS Pratinjau umum
Mesin pihak ketiga resmi (melalui API mesin resmi OneLake) Ya (saat diimplementasikan oleh mesin) Pratinjau umum

Mesin pihak ketiga yang diotorisasi

Keamanan OneLake mendukung penegakan oleh mesin pihak ketiga yang diberi wewenang melalui model mesin yang diberi wewenang. Mesin eksternal dapat mendaftar sebagai mesin yang diotorisasi dan mengambil definisi keamanan serta akses efektif yang telah dihitung sebelumnya melalui API dari OneLake. Mesin ini memberlakukan izin tabel, RLS, dan CLS saat kueri dijalankan di lapisan komputasi mereka sendiri. OneLake tetap menjadi sumber informasi utama untuk kontrol akses, sementara mesin mempertahankan kontrol penuh atas pengoptimalan dan eksekusi kueri.

Untuk informasi selengkapnya tentang mengintegrasikan mesin dengan keamanan OneLake, lihat Gambaran umum integrasi keamanan OneLake.

Detail model kontrol akses keamanan OneLake

Bagian ini menyediakan detail tentang bagaimana peran keamanan OneLake memberikan akses kepada cakupan tertentu, bagaimana akses tersebut beroperasi, dan bagaimana akses ditentukan di antara beberapa peran dan jenis akses.

Keamanan tingkat tabel

Semua tabel OneLake diwakili oleh folder di danau, tetapi tidak semua folder di danau adalah tabel dari perspektif keamanan OneLake dan mesin kueri di Fabric. Untuk dianggap sebagai tabel yang valid, kondisi berikut harus dipenuhi:

  • Folder ada di direktori Tabel/item. Untuk item yang menggunakan skema, folder juga harus berada di dalam folder skema yang valid.
  • Folder berisi folder _delta_log dengan file JSON terkait untuk metadata tabel.
  • Folder tidak memuat pintasan anak.

Tabel apa pun yang tidak memenuhi kriteria tersebut akan memiliki akses ditolak jika keamanan tingkat tabel dikonfigurasi pada tabel tersebut.

Keamanan metadata

Izin Baca keamanan OneLake memberikan akses penuh ke data dan metadata dalam tabel. Untuk pengguna tanpa akses ke tabel, data tidak pernah diekspos. Ini juga berlaku untuk keamanan tingkat kolom dan kemampuan pengguna untuk melihat atau tidak melihat kolom dalam tabel tersebut. Namun, keamanan OneLake tidak menjamin bahwa metadata untuk tabel tidak akan dapat diakses, dan pesan dan pengalaman kesalahan tertentu mungkin menampilkan nama kolom.

Pewarisan izin

Untuk setiap folder tertentu, izin keamanan OneLake selalu diwariskan ke seluruh hierarki file dan subfolder folder tersebut.

Misalnya, pertimbangkan hierarki lakehouse berikut ini di OneLake:

Tables/
──── (empty folder)
Files/
────folder1
│   │   file11.txt
│   │
│   └───subfolder11
│       │   file1111.txt
|       │
│       └───subfolder111
|            │   file1111.txt
│   
└───folder2
    │   file21.txt

Anda membuat dua peran untuk rumah danau ini. Role1 memberikan izin baca ke folder1, dan Role2 memberikan izin baca ke folder2.

Untuk hierarki yang diberikan, izin keamanan OneLake untuk Role1 dan Role2 diwariskan dengan cara berikut:

  • Peran1: Membaca folder 1

    │   │   file11.txt
│   │
│   └───subfolder11
│       │   file1111.txt
|       │
│       └───subfolder111
|            │   file1111.txt

  • Peran2: Akses folder2

        │   file21.txt

Penelusuran dan penyajian dalam keamanan OneLake

Keamanan OneLake menyediakan penelusuran otomatis elemen utama untuk memastikan bahwa data mudah ditemukan. Memberikan izin Baca kepada pengguna untuk subfolder11 memungkinkan pengguna untuk mencantumkan dan mengakses direktori induk folder1. Fungsi ini mirip dengan izin folder di Windows di mana memberikan akses ke subfolder memungkinkan penelusuran dan melintasi direktori induk. Akses daftar dan traversal yang diberikan kepada pihak induk tidak meluas ke item lain di luar pihak induk langsung, menjaga keamanan folder lain.

Misalnya, pertimbangkanlah hierarki "lakehouse" berikut di OneLake.

Tables/
──── (empty folder)
Files/
────folder1
│   │   file11.txt
│   │
│   └───subfolder11
│       │   file111.txt
|       │
│       └───subfolder111
|            │   file1111.txt
│   
└───folder2
    │   file21.txt

Untuk hierarki yang diberikan, izin keamanan OneLake untuk 'Role1' menyediakan akses berikut. Akses ke file11.txt tidak terlihat karena bukan induk dari subfolder11. Demikian juga untuk Peran 2, file111.txt juga tidak terlihat.

  • Peran 1: Membaca subfolder11

    Files/
────folder1
│   │
│   └───subfolder11
│       │   file111.txt
|       │
│       └───subfolder111
|            │   file1111.txt

  • Peranan2: Membaca subfolder111

    Files/
────folder1
│   │
│   └───subfolder11
|       │
│       └───subfolder111
|            │   file1111.txt

Untuk pintasan, cara daftar bekerja sedikit berbeda. Pintasan ke sumber data eksternal berperilaku sama seperti folder, namun pintasan ke lokasi OneLake lainnya memiliki perilaku khusus. Izin target dari pintasan menentukan akses ke pintasan OneLake. Saat mencantumkan pintasan, tidak ada panggilan yang dilakukan untuk memverifikasi akses target. Akibatnya, saat mencantumkan direktori, semua pintasan internal dikembalikan terlepas dari akses pengguna ke target. Saat pengguna mencoba membuka pintasan, pemeriksaan akses dilakukan dan pengguna hanya melihat data yang mereka memiliki izin yang diperlukan untuk melihatnya. Untuk informasi selengkapnya tentang pintasan, lihat bagian keamanan pintasan .

Pertimbangkan hierarki folder berikut yang berisi pintasan.

Files/
────folder1
│   
└───shortcut2
|
└───shortcut3

  • Peran1: Membaca folder 1

    Files/
────folder1
│   
└───shortcut2
|
└───shortcut3

  • Peran2: Tidak ada izin yang ditentukan

    Files/
│   
└───shortcut2
|
└───shortcut3

Keamanan tingkat baris

Keamanan OneLake memungkinkan pengguna menentukan keamanan tingkat baris dengan menulis predikat SQL untuk membatasi data apa yang ditampilkan kepada pengguna. RLS beroperasi dengan menampilkan baris di mana predikat dievaluasi menjadi benar. Untuk informasi selengkapnya, lihat keamanan tingkat baris.

Keamanan tingkat baris mengevaluasi data string sebagai tidak peka terhadap huruf besar/kecil, menggunakan kolasi berikut guna pengurutan dan perbandingan: Latin1_General_100_CI_AS_KS_WS_SC_UTF8

Saat menggunakan keamanan tingkat baris, pastikan bahwa pernyataan RLS bersih dan mudah dipahami. Gunakan kolom bilangan bulat untuk mengurutkan dan lebih besar dari atau kurang dari operasi. Hindari kesetaraan string jika Anda tidak mengetahui format data input, terutama dalam kaitannya dengan karakter unicode atau sensitivitas aksen.

Keamanan tingkat kolom

Keamanan OneLake mendukung pembatasan akses ke kolom dengan menghapus (menyembunyikan) akses pengguna ke kolom. Kolom tersembunyi diperlakukan sebagai tidak memiliki izin yang ditetapkan padanya, menghasilkan kebijakan default tanpa akses. Kolom tersembunyi tidak akan terlihat oleh pengguna, dan kueri pada data yang berisi kolom tersembunyi tidak mengembalikan data untuk kolom tersebut. Seperti yang dicatat dalam keamanan metadata ada kasus tertentu di mana metadata kolom mungkin masih terlihat.

Keamanan tingkat kolom juga mengikuti perilaku yang lebih ketat di Titik Akhir SQL dengan beroperasi melalui semantik tolak. Penolakan pada kolom di Endpoint SQL memastikan bahwa semua akses ke kolom diblokir, bahkan jika beberapa peran digabungkan untuk memberikan akses. Akibatnya, CLS di Titik Akhir SQL beroperasi menggunakan persimpangan dari semua peran yang diikuti oleh pengguna alih-alih perilaku gabungan di tempat untuk semua jenis izin lainnya. Lihat bagian Mengevaluasi beberapa peran keamanan OneLake untuk informasi selengkapnya tentang bagaimana peran digabungkan.

Izin BacaTulis

Izin ReadWrite memberi pengguna dengan hak akses baca saja kemampuan untuk melakukan operasi tulis ke item tertentu. Izin ReadWrite hanya berlaku untuk Pemirsa atau pengguna dengan izin Baca pada item. Menetapkan akses ReadWrite ke Admin, Anggota, atau Kontributor tidak berpengaruh karena peran tersebut sudah memiliki izin tersebut secara implisit.

Akses ReadWrite memungkinkan pengguna melakukan operasi tulis melalui notebook Spark, penjelajah file OneLake, atau API OneLake.

Izin ReadWrite beroperasi dengan cara berikut:

  • Izin ReadWrite mencakup semua hak istimewa yang diberikan oleh izin Baca.
  • Pengguna dengan izin ReadWrite pada objek dapat melakukan operasi tulis pada objek tersebut, inklusif. Artinya, setiap operasi juga dapat dilakukan pada objek itu sendiri.
  • ReadWrite memungkinkan tindakan berikut:
    • Membuat folder atau tabel baru
    • Menghapus folder atau tabel
    • Mengganti nama folder atau tabel
    • Mengunggah atau mengedit file
    • Membuat jalan pintas
    • Menghapus sebuah pintasan
    • Mengganti nama pintasan
  • Peran keamanan OneLake dengan akses ReadWrite tidak boleh berisi batasan RLS atau CLS.
  • Karena Fabric hanya mendukung penulisan mesin tunggal ke data, pengguna dengan izin ReadWrite pada objek hanya dapat Menulis ke data tersebut melalui OneLake. Namun, operasi pembacaan akan diberlakukan secara konsisten di seluruh mesin kueri.

Pintasan

Gambaran umum pintasan

Keamanan OneLake terintegrasi dengan pintasan di OneLake untuk memastikan data di dalam dan di luar OneLake dapat dengan mudah diamankan. Ada dua mode autentikasi utama untuk pintasan:

  • Pintasan passthrough (SSO): Kredensial pengguna yang melakukan kueri diperiksa terhadap target pintasan untuk menentukan data mana yang boleh dilihat.
  • Pintasan yang didelegasikan: Pintasan menggunakan kredensial tetap untuk mengakses target dan pengguna kueri dievaluasi terhadap keamanan OneLake sebelum memeriksa akses kredensial yang didelegasikan ke sumber.

Selain itu, izin keamanan OneLake dievaluasi saat membuat pintasan apa pun di OneLake. Baca tentang izin pintasan dalam dokumen keamanan pintasan.

Keamanan OneLake pada pintasan lewat langsung

Keamanan yang diatur pada folder OneLake selalu diterapkan di semua pintasan internal untuk membatasi akses ke jalur tujuan pintasan. Saat pengguna mengakses data melalui pintasan ke lokasi OneLake lain, identitas pengguna panggilan digunakan untuk mengotorisasi akses ke data di jalur target pintasan. Akibatnya, pengguna ini harus memiliki izin keamanan OneLake di lokasi target untuk membaca data.

Penting

Saat mengakses pintasan melalui model semantik Power BI menggunakan Direct Lake melalui mesin SQL atau T-SQL dalam mode Identitas yang didelegasikan, identitas pengguna panggilan tidak diteruskan ke target pintasan. Sebagai gantinya, identitas pemilik item panggilan diteruskan, mendelegasikan akses ke pengguna yang melakukan panggilan. Untuk mengatasinya, gunakan model semantik Power BI dalam mode Direct Lake over OneLake atau T-SQL dalam mode identitas Pengguna.

Menentukan izin keamanan OneLake untuk pintasan internal tidak diizinkan dan keamanan harus ditentukan pada folder target yang terletak di item target. Item target harus merupakan jenis item yang mendukung peran keamanan OneLake. Jika item target tidak mendukung keamanan OneLake, akses pengguna dievaluasi berdasarkan apakah mereka memiliki izin Fabric ReadAll pada item target. Pengguna tidak memerlukan izin Fabric Read pada item untuk mengaksesnya melalui pintasan.

Keamanan OneLake pada pintasan yang didelegasikan

OneLake mendukung penentuan izin untuk pintasan seperti ADLS, S3, dan Dataverse. Dalam kasus ini, hak akses diterapkan sebagai tambahan pada model otorisasi yang telah didelegasikan dan diaktifkan untuk jenis pintasan ini.

Misalkan pengguna1 membuat pintasan S3 di lakehouse yang menunjuk ke folder dalam bucket AWS S3. Kemudian pengguna2 mencoba mengakses data dalam pintasan ini.

Apakah koneksi S3 mengotorisasi akses untuk pengguna yang didelegasikan1? Apakah keamanan OneLake mengotorisasi akses untuk pengguna2 yang meminta? Hasil: Bisakah pengguna2 mengakses data di Pintasan S3?
Ya Ya Ya
Tidak Tidak Tidak
Tidak Ya Tidak
Ya Tidak Tidak

Izin keamanan OneLake dapat ditentukan baik untuk seluruh cakupan pintasan atau untuk subfolder yang dipilih. Izin yang diatur pada folder mewarisi dengan cara berurutan ke semua subfolder, bahkan jika subfolder tersebut berada di dalam pintasan. Keamanan yang diatur pada pintasan eksternal dapat dilingkupi untuk memberikan akses apakah ke seluruh pintasan, maupun subjalur apa pun di dalam pintasan. Pintasan internal lain yang menunjuk ke pintasan eksternal masih mengharuskan pengguna memiliki akses ke pintasan eksternal asli.

Tidak seperti jenis akses lain dalam keamanan OneLake, pengguna yang mengakses pintasan eksternal memerlukan izin Fabric Read pada item data tempat pintasan eksternal berada. Ini diperlukan untuk menyelesaikan koneksi ke sistem eksternal dengan aman.

Pelajari selengkapnya tentang pintasan S3, ADLS, dan Dataverse di pintasan OneLake.

Mengevaluasi beberapa peran keamanan OneLake

Pengguna dapat menjadi anggota dari beberapa peran keamanan OneLake yang berbeda, masing-masing menyediakan aksesnya sendiri ke data. Kombinasi peran ini bersama-sama disebut "peran efektif" dan adalah apa yang akan dilihat pengguna saat mengakses data di OneLake. Peran digabungkan dalam keamanan OneLake menggunakan UNION atau model paling tidak membatasi. Ini berarti jika Role1 memberikan akses ke TableA, dan Role2 memberikan akses ke TableB, maka pengguna akan dapat melihat TableA dan TableB.

Peran keamanan OneLake juga berisi keamanan tingkat baris dan kolom, yang membatasi akses ke baris dan kolom tabel. Setiap kebijakan RLS dan CLS ada dalam peran dan membatasi akses ke data untuk semua pengguna dalam satu peran tersebut. Misalnya, jika Role1 memberikan akses ke Table1, tetapi memiliki RLS pada Table1 dan hanya menampilkan beberapa kolom dari Table1, maka peran efektif untuk Role1 akan menjadi subset dari RLS dan CLS pada Table1. Ini dapat dinyatakan sebagai (R1ols n R1cls n R1rls) di mana n adalah INTERSECTION dari setiap komponen dalam peran.

Saat berhadapan dengan beberapa peran, RLS dan CLS digabungkan dengan semantik UNION di tabel yang bersangkutan. CLS adalah gabungan langsung kumpulan dari tabel-tabel yang terlihat dalam setiap peran. RLS digabungkan di seluruh predikat menggunakan operator OR. Misalnya, WHERE city = 'Redmond' OR city = 'New York'.

Untuk mengevaluasi beberapa peran yang masing-masing memiliki RLS atau CLS, setiap peran pertama-tama ditentukan berdasarkan akses yang diberikan oleh peran itu sendiri. Ini berarti mengevaluasi PERSIMPANGAN dari keamanan pada tingkat objek, baris, dan kolom. Setiap peran yang dievaluasi kemudian dikombinasikan melalui operasi UNION dengan semua peran lain yang merupakan anggota pengguna. Output adalah peran efektif untuk pengguna tersebut. Ini dapat diekspresikan sebagai:

( (R1ols n R1cls n R1rls) u (R2ols n R2cls n R2rls) )

Terakhir, setiap jalan pintas di lakehouse menghasilkan sekumpulan peran yang dihasilkan berdasarkan inferensi yang digunakan untuk meneruskan izin target jalan pintas ke item yang sedang diakses. Peran yang disimpulkan beroperasi dengan cara yang sama dengan peran yang tidak disimpulkan kecuali peran tersebut diselesaikan terlebih dahulu pada target pintasan sebelum dikombinasikan dengan peran di lakehouse pintasan. Ini memastikan bahwa setiap pewarisan izin pada shortcut lakehouse diputus dan peran yang disimpulkan dievaluasi dengan benar. Logika kombinasi lengkap kemudian dapat diekspresikan sebagai:

( (R1ols n R1cls n R1rls) u (R2ols n R2cls n R2rls) ) n ( (R1'ols n R1'cls n R1'rls) u (R2'ols n R2'cls n R2'rls)) )

Di mana R1' dan R2' adalah peran yang disimpulkan dan R1 dan R2 adalah peran lakehouse pintasan.

Penting

Pengguna yang sama dengan dua atau lebih peran yang memiliki kolom yang diizinkan berbeda tidak didukung jika salah satu dari peran tersebut juga memiliki pernyataan RLS. Misalnya, Role1 mengizinkan kolom c1 dan c2 dengan RLS, dan Role2 mengizinkan kolom c2 dan c3.

Batasan keamanan OneLake

  • Jika Anda menetapkan peran keamanan OneLake ke pengguna tamu B2B, Anda harus mengonfigurasi pengaturan kolaborasi eksternal untuk B2B di Microsoft Entra External ID. Pengaturan akses pengguna tamu harus diatur ke Pengguna tamu memiliki akses yang sama dengan anggota (paling inklusif).

  • Jika Anda menambahkan daftar distribusi ke sebuah peran dalam keamanan OneLake, endpoint analitik SQL tidak dapat mengidentifikasi anggota daftar tersebut untuk menegakkan kontrol akses. Akibatnya, pengguna tampak bukan anggota peran tersebut saat mereka mengakses endpoint analitik SQL. Model semantik Direct Lake di SQL juga tunduk pada batasan ini.

  • Notebook Spark mensyaratkan lingkungan versi 3.5 atau lebih tinggi dan menggunakan Fabric runtime 1.3.

  • Pratinjau data untuk tabel aman RLS dan CLS tidak didukung untuk lakehouse non-skema. Kami merekomendasikan menggunakan lakehouse yang memiliki skema dengan keamanan OneLake.

  • Keamanan OneLake tidak berfungsi dengan Azure Data Share atau Purview Data Share. Untuk informasi selengkapnya, lihat Azure Data Share.

  • Tabel berikut ini menyediakan batasan peran akses data OneLake.

    Skenario Batas
    Jumlah maksimum peran keamanan OneLake untuk tiap Item di Fabric 250 peran per entitas1
    Jumlah maksimum anggota untuk setiap peran keamanan OneLake 500 pengguna atau grup pengguna per peran
    Jumlah maksimum izin per peran keamanan OneLake 500 izin untuk setiap peran

1 Anda dapat meminta peningkatan peran per item menjadi 1000. Untuk meminta peningkatan, hubungi (Dukungan Azure.)[https://azure.microsoft.com/support/faq/]

Latensi dalam keamanan OneLake

  • Perubahan pada definisi peran membutuhkan waktu sekitar 5 menit untuk diterapkan.
  • Perubahan pada grup pengguna dalam peran keamanan OneLake membutuhkan waktu sekitar satu jam bagi OneLake untuk menerapkan izin peran pada grup pengguna yang diperbarui.
    • Beberapa mesin Fabric memiliki lapisan cache sendiri, dapat memerlukan waktu satu jam tambahan untuk memperbarui akses pada semua sistem.
  • Last updated on