Mengintegrasikan keamanan Direct Lake

Keamanan Direct Lake memastikan bahwa hanya pengguna yang berwenang yang dapat mengkueri tabel Delta di OneLake. Anda dapat mengelola izin akses data melalui peran ruang kerja. Kontributor, anggota, dan admin ruang kerja dapat membaca data di OneLake. Anda juga dapat memberikan akses ke data di OneLake melalui izin tingkat item dan komputasi. Opsi ketiga adalah memanfaatkan keamanan OneLake untuk memberlakukan keamanan berbasis peran terperinci di semua mesin komputasi Fabric. Artikel ini menjelaskan cara menyelaraskan model izin, memilih akses menyeluruh (SSO) atau identitas tetap, dan memanfaatkan keamanan tingkat objek (OLS) dan keamanan tingkat baris (RLS). Pelajari selengkapnya di Ringkasan keamanan OneLake.

Konsep dan terminologi utama

Artikel ini mengasumsikan Anda terbiasa dengan konsep-konsep ini:

• Direct Lake menggunakan ekspresi M bersama dalam metadata model semantik untuk mereferensikan sumber data melalui fungsi akses data Power Query: AzureStorage.DataLake untuk Direct Lake di OneLake dan Sql.Database untuk Direct Lake pada titik akhir SQL. Namun, Direct Lake tidak menggunakan fungsi-fungsi ini untuk membaca tabel Delta sumber. Ini membaca tabel Delta langsung melalui API OneLake.
• Untuk memastikan hanya pengguna yang berwenang yang mengkueri data, Direct Lake memeriksa izin akses data dari identitas yang efektif. Identitas yang efektif tergantung pada konfigurasi koneksi data. Secara default, Direct Lake menggunakan SSO (Microsoft Entra ID) dan menggunakan identitas pengguna saat ini yang mengkueri model semantik. Anda juga dapat mengikat model Direct Lake ke koneksi cloud eksplisit untuk memberikan identitas tetap.
• Jika Anda memberikan izin akses data melalui peran ruang kerja, hanya anggota peran Kontributor (atau lebih tinggi) yang dapat membaca data di OneLake. Namun, Penonton Ruang Kerja tidak memiliki izin baca di OneLake. Pemirsa dan pengguna yang bukan anggota peran ruang kerja bisa mendapatkan akses baca melalui kombinasi izin item, izin komputasi, atau peran keamanan OneLake.
• Keamanan OneLake memungkinkan anggota peran Admin Ruang Kerja dan Anggota Ruang Kerja menentukan keamanan berbasis peran terperinci untuk pengguna dalam peran Penampil. Tentukan tabel penampil atau pengguna dengan izin baca eksplisit dapat mengakses dan mengecualikan baris atau kolom tertentu. Untuk mempelajari selengkapnya tentang peran keamanan OneLake, lihat Keamanan tabel di OneLake, Keamanan tingkat kolom di OneLake, dan RLS di OneLake.

Konfigurasi koneksi

Konfigurasikan koneksi data untuk model Direct Lake dengan cara yang sama seperti jenis model semantik lainnya. Lihat Menyambungkan ke sumber data cloud di layanan Power BI untuk detailnya.

Karena Direct Lake hanya terhubung ke sumber data Fabric, konfigurasi SSO default (MICROSOFT Entra ID) biasanya berfungsi, sehingga Anda tidak perlu mengikat model semantik ke koneksi data eksplisit. Pendekatan ini mengurangi kompleksitas konfigurasi dan menurunkan overhead manajemen.

Dengan SSO (MICROSOFT Entra ID), Direct Lake memeriksa bahwa pengguna saat ini yang mengkueri model semantik memiliki akses baca ke data. Hanya pengguna dengan akses baca yang dapat mengkueri data. Cuplikan layar berikut menunjukkan model Direct Lake menggunakan konfigurasi SSO default.

Saat Anda menggunakan koneksi data eksplisit dengan identitas tetap alih-alih SSO, Direct Lake tidak mengharuskan setiap pengguna untuk memiliki izin baca pada data yang mendasar. Jika SSO Microsoft Entra tetap dinonaktifkan dalam koneksi data, izin identitas yang tetap menentukan data apa yang dapat diakses oleh Direct Lake.

Nota

Anda dapat mengonfigurasi koneksi data untuk menggunakan SSO dan identitas tetap. Direct Lake memeriksa izin pengguna saat ini saat query dilakukan dan menggunakan identitas tetap untuk pembingkaian dan transkode saat penyegaran. Untuk menggunakan identitas tetap untuk kueri dan refresh, pastikan SSO dinonaktifkan dalam konfigurasi koneksi data.

Petunjuk / Saran

Gunakan SSO untuk skenario interaktif di mana otorisasi per pengguna diperlukan. Gunakan koneksi cloud dengan identitas tetap untuk skenario konsumen yang disematkan atau hanya-baca, di mana akses pada tingkat sumber dibatasi untuk satu akun layanan. Terapkan prinsip hak istimewa paling sedikit pada tingkat sumber dan ruang kerja, serta uji dan validasi perilaku untuk kedua mode autentikasi sebelum penyebaran produksi.

Persyaratan autentikasi

Model Direct Lake menggunakan autentikasi ID Microsoft Entra. Dalam konfigurasi koneksi data, pilih OAuth 2.0, Perwakilan Layanan, atau Identitas Ruang Kerja sebagai metode autentikasi. Metode lain, seperti autentikasi kunci atau SAS, mungkin muncul di antarmuka pengguna konfigurasi tetapi tidak didukung untuk model Direct Lake.

Persyaratan izin

Persyaratan izin berbeda antara Direct Lake pada titik akhir SQL dan Direct Lake di OneLake. Ini karena Direct Lake pada titik akhir SQL bergantung pada Titik Akhir Analitik SQL dari sumber data target, sedangkan Direct Lake di OneLake menggunakan API OneLake untuk pemeriksaan izin.

Direct Lake pada endpoint SQL

Direct Lake di titik akhir SQL melakukan pemeriksaan izin melalui titik akhir analitik SQL untuk menentukan apakah identitas efektif yang mencoba mengakses data memiliki izin akses data yang diperlukan. Perlu dicatat, identitas efektif tidak memerlukan izin langsung untuk membaca tabel Delta di OneLake. Ini cukup untuk memiliki akses baca ke artefak Fabric, seperti lakehouse, dan izin SELECT pada tabel melalui titik akhir analitik SQL-nya. Itu karena Fabric memberikan izin yang diperlukan ke model semantik untuk membaca tabel Delta dan file Parquet terkait (untuk memuat data kolom ke dalam memori). Model semantik memiliki izin untuk membaca titik akhir analitik SQL secara berkala untuk memeriksa data apa yang dapat diakses pengguna kueri (atau identitas tetap).

Danau Langsung di OneLake

Direct Lake di OneLake tidak menggunakan titik akhir analitik SQL untuk pemeriksaan izin. Ini menggunakan OneLake Security. Ketika OneLake Security diaktifkan, Direct Lake di OneLake menggunakan pengguna saat ini (atau identitas tetap) untuk menyelesaikan peran OneLake Security dan memberlakukan OLS dan RLS pada artefak Fabric target. Jika OneLake Security tidak diaktifkan, Direct Lake pada OneLake memerlukan identitas yang efektif untuk memiliki izin "Read" dan "ReadAll" pada artefak Fabric target guna mengakses tabel Delta di dalam OneLake. Untuk informasi selengkapnya tentang izin Baca dan BacaSemua, lihat bagian Izin item di artikel Gambaran umum keamanan OneLake.

Nota

Kontributor (atau lebih tinggi) memiliki izin Baca dan BacaSemua di OneLake. Pemirsa dan pengguna yang bukan anggota suatu peran di ruang kerja harus diberikan izin Baca dan Baca Semua atau ditambahkan ke grup keamanan OneLake. Untuk informasi selengkapnya tentang mengelola grup keamanan OneLake, lihat Model kontrol akses data OneLake.

Pengguna Direct Lake

Skenario berikut mencantumkan persyaratan izin minimum.

Scenario	Direct Lake pada endpoint SQL	Danau Langsung di OneLake	Komentar
Pengguna dapat melihat laporan	- Berikan izin Baca untuk laporan dan izin Baca untuk model semantik. - Jika Direct Lake menggunakan SSO, berikan pengguna setidaknya izin Baca untuk artefak Fabric target dan izin SELECT untuk tabel.	- Berikan izin Baca untuk laporan dan izin Baca untuk model semantik. - Jika Direct Lake menggunakan SSO, beri pengguna setidaknya izin Baca untuk artefak Fabric target dan tambahkan mereka ke peran keamanan OneLake, atau beri mereka izin BacaSemua.	Laporan tidak perlu berada di ruang kerja yang sama dengan model semantik. Untuk informasi lebih lanjut, lihat Strategi untuk konsumen baca-saja.
Pengguna dapat membuat laporan	- Berikan izin Build untuk model semantik. - Jika Direct Lake menggunakan SSO, berikan pengguna setidaknya izin Baca untuk artefak Fabric target dan izin SELECT untuk tabel.	- Berikan izin Build untuk model semantik. - Jika Direct Lake menggunakan SSO, beri pengguna setidaknya izin Baca untuk artefak Fabric target dan tambahkan mereka ke peran keamanan OneLake, atau beri mereka izin BacaSemua.	Pengguna hanya dapat membuat laporan pada tabel dan kolom yang dapat mereka akses. Ini mungkin merupakan subset kumpulan lengkap tabel dan kolom dalam model. Untuk informasi selengkapnya, lihat Strategi untuk pembuat konten.
Pengguna dapat mengkueri model semantik tetapi ditolak mengkueri titik akhir analitik lakehouse atau SQL	- Ikat model Direct Lake ke koneksi cloud dengan identitas tetap dan biarkan SSO dinonaktifkan. - Berikan identitas tetap setidaknya izin Baca untuk artefak Fabric target dan izin SELECT untuk tabel. - Jangan beri pengguna izin apa pun untuk artefak Fabric target.	- Ikat model Direct Lake ke koneksi cloud dengan identitas tetap dan biarkan SSO dinonaktifkan. - Berikan identitas tetap setidaknya izin Baca untuk artefak Fabric target dan tambahkan ke peran keamanan OneLake atau berikan izin ReadAll . - Jangan beri pengguna izin apa pun untuk artefak Fabric target.	Hanya cocok saat koneksi cloud menggunakan identitas tetap.
Pengguna dapat meminta model semantik dan titik akhir analitik SQL tetapi tidak diizinkan untuk mengakses lakehouse	- Berikan izin Read dan ReadData untuk artefak Fabric target.	Tidak dapat diterapkan.	Penting: Kueri yang dikirim ke titik akhir analitik SQL akan melewati izin akses data yang diberlakukan oleh model semantik.
Mengelola model semantik, termasuk pengaturan refresh	- Membutuhkan kepemilikan model semantik.	- Membutuhkan kepemilikan model semantik.	Untuk informasi selengkapnya, lihat kepemilikan model semantik.

Penting

Selalu uji izin sebelum merilis model semantik Anda dan melaporkan ke produksi.

Untuk informasi selengkapnya, lihat izin model Semantik .

Pemilik Direct Lake

Selain identitas yang efektif (pengguna saat ini atau identitas tetap), Direct Lake juga mengharuskan pemilik model semantik memiliki akses baca ke tabel sumber sehingga Direct Lake dapat membingkai model semantik sebagai bagian dari refresh data. Tidak peduli siapa yang me-refresh model Direct Lake, Direct Lake memeriksa izin pemilik untuk memastikan model diizinkan untuk mengakses data. Persyaratan izin akses data pemilik sama dengan untuk pengguna yang mengkueri model.

Jika pemilik model semantik tidak memiliki izin akses data yang diperlukan, Direct Lake menimbulkan kesalahan berikut selama pembingkaian: We cannot refresh this semantic model because one or multiple source tables either do not exist or access was denied. Please contact a data source admin to verify that the tables exist and ensure that the owner of this semantic model does have read access to these tables. Some restricted tables including fully restricted and partially restricted (indicating column constraints): '\<list of tables\>'.

Pintasan ke tabel sumber

Pintasan adalah objek OneLake yang Anda tambahkan ke Fabric lakehouse atau artefak Fabric lainnya yang menunjuk pada lokasi penyimpanan internal atau eksternal. Dalam model Direct Lake, tabel-tabel Delta yang ditambahkan melalui pintasan muncul sebagai asli dalam artefak Fabric yang terhubung karena pintasan menjadi transparan ketika Anda mengakses data melalui OneLake API.

Saat Anda mengakses pintasan melalui Direct Lake melalui titik akhir SQL, Direct Lake terlebih dahulu memvalidasi bahwa identitas yang efektif (pengguna saat ini atau identitas tetap) dapat mengakses tabel di sumber data model semantik. Untuk pintasan internal, setelah pemeriksaan tersebut berhasil, Direct Lake menggunakan identitas pemilik sumber data untuk membaca tabel Delta melalui pintasan di artefak Fabric dari tabel. Pemilik sumber data harus memiliki izin akses di lokasi OneLake target. Untuk pintasan eksternal, pemilik sumber data juga memerlukan Izin penggunaan pada koneksi cloud ke sistem eksternal yang menghosting tabel Delta. Untuk informasi lebih lanjut, lihat pintasan OneLake .

Direct Lake melalui OneLake memiliki persyaratan izin yang berbeda karena Titik Akhir Analitik SQL tidak terlibat. Saat pengguna mengakses data melalui pintasan internal ke lokasi OneLake lain, identitas efektif (pengguna saat ini atau identitas tetap) harus memiliki izin di lokasi target. Identitas yang efektif harus Kontributor (atau lebih tinggi), memiliki izin Baca dan BacaSemua, atau berada dalam peran keamanan di OneLake yang memberikan akses baca.

Keamanan tingkat objek (OLS) dan keamanan tingkat baris (RLS)

Model OneLake Security dan Direct Lake mendukung OLS dan RLS. OLS memungkinkan pemilik dan admin artefak untuk mengamankan tabel atau kolom tertentu. RLS dapat digunakan untuk membatasi akses data di tingkat baris berdasarkan filter. Anda dapat menentukan OLS dan RLS di OneLake Security, dalam model Direct Lake, atau di kedua lokasi.

Penting

Direct Lake tidak mendukung SQL Analytics Endpoint OLS/RLS. Untuk mengembalikan data yang benar, jika sebuah artefak Fabric menggunakan OLS atau RLS, Direct Lake pada titik akhir SQL akan beralih kembali ke mode DirectQuery. Jika fallback DirectQuery dinonaktifkan, kueri melalui titik akhir SQL gagal saat OLS/RLS ditentukan di Titik Akhir Analitik SQL. Direct Lake melalui OneLake mengatasi batasan ini.

Direct Lake di OneLake OLS/RLS dengan OneLake Security OLS/RLS

Direct Lake on OneLake mengevaluasi akses ke objek yang dilindungi oleh OLS/RLS dengan menentukan peran OneLake Security dari identitas yang efektif dan menerapkan aturan OLS/RLS yang ditetapkan. Peran OneLake Security ditangani sama dengan peran Direct Lake. Jika identitas efektif memiliki beberapa peran dalam OneLake Security dan Direct Lake, Direct Lake pertama-tama menghimpun peran OneLake Security, kemudian beririsan dengan hasil peran Direct Lake.

Tabel ini mencantumkan situasi pemecahan masalah umum yang disebabkan oleh aturan OneLake Security dan Direct Lake yang bertentangan.

Scenario	Komentar
Tidak ada baris yang dikembalikan karena pemfilteran RLS	Jika identitas efektif tidak memiliki izin akses tingkat baris, kueri dapat mengembalikan hasil kosong. Perilaku ini diharapkan ketika filter RLS mengecualikan semua baris untuk pengguna saat ini.
Tidak dapat menemukan tabel Kolom tidak dapat ditemukan Gagal menyelesaikan nama Bukan tabel, variabel, atau nama fungsi yang valid	Kesalahan ini biasanya terjadi ketika izin objek hilang setelah menerapkan peran OneLake Security.

Perbedaan cakupan OLS/RLS

Memberlakukan OLS dan RLS di OneLake Security menerapkan aturan di semua mesin komputasi dan memastikan kontrol akses terpadu untuk pengguna. Artinya, terlepas dari mesin pengolah komputasi seperti lakehouse, gudang data, model semantik, atau artefak lainnya, aturan OneLake Security mengontrol akses data oleh pengguna. Sebaliknya, OLS/RLS yang ditentukan dalam model semantik Direct Lake hanya berlaku dalam cakupan model tersebut. Mesin komputasi lain tidak menerapkan aturan keamanan Direct Lake ini, yang dapat menghasilkan hasil yang berbeda saat pengguna mengakses data melalui jalur lain.

Penting

Saat Anda menggunakan OneLake Security OLS/RLS dan Direct Lake OLS/RLS, pengguna yang memiliki akses OneLake masih dapat mengambil dan bekerja dengan data—bahkan jika aturan model Direct Lake membatasi data lebih lanjut—karena aturan tingkat model tidak melampaui model. Gunakan OneLake Security untuk kontrol akses komprehensif di semua mesin komputasi.

OneLake OLS dan metadata model semantik

Metadata model semantik mencakup definisi tabel, kolom, hubungan, dan elemen skema lainnya. Pengguna dengan izin build atau yang lebih tinggi dapat melihat metadata model melalui XML untuk Analisis (XMLA) dan REST API. Untuk informasi selengkapnya, lihat izin model Semantik .

Untuk melindungi nama tabel dan kolom sensitif di OneLake dengan OneLake OLS, ingatlah bahwa OneLake Security hanya berlaku untuk anggota peran Penampil ruang kerja. OneLake OLS tidak mencegah anggota peran ruang kerja Kontributor (atau lebih tinggi) menemukan tabel atau kolom aman karena sudah memiliki izin Tulis ke semua artefak ruang kerja. Anggota peran Penampil dengan izin build atau yang lebih tinggi pada model Direct Lake dapat menemukan informasi skema sensitif melalui metadata model semantik. Pemirsa dengan hak istimewa yang lebih tinggi ini masih tidak memiliki akses data, tetapi mereka dapat melihat bahwa tabel dan kolom aman ada.

Model Direct Lake mungkin ada di ruang kerja yang sama dengan artefak sumber atau di ruang kerja terpisah. Berikan penampil dengan tingkat izin build (atau lebih tinggi) di ruang kerja yang sama akses ke model Direct Lake melalui izin item. Di ruang kerja terpisah, pengguna mungkin merupakan Kontributor (atau lebih tinggi) atau memiliki izin item build (atau lebih tinggi) untuk mengakses metadata model.

Integrasi OneLake OLS dan Git

Integrasi Git memungkinkan pengembang untuk mengintegrasikan proses manajemen siklus hidup aplikasi (ALM) mereka ke dalam platform Fabric. Repositori Git mempertahankan struktur ruang kerja, termasuk semua artefak yang didukung. Pengembang memiliki visibilitas penuh ke metadata semua item mereka di repositori Git. Metadata model Direct Lake memungkinkan mereka melihat bahwa tabel atau kolom aman ada meskipun mereka tidak memiliki akses ke sumber data target di ruang kerja lain. Untuk informasi selengkapnya, lihat Apa itu integrasi Microsoft Fabric Git?

Bagaimana kueri dievaluasi di Direct Lake di SQL

Alasan untuk mengembangkan model semantik Direct Lake adalah untuk mencapai kueri performa tinggi atas data dalam volume besar di OneLake. Oleh karena itu, Anda harus berusaha untuk merancang solusi yang memaksimalkan kemungkinan kueri yang dilakukan dalam memori.

Langkah-langkah berikut menggambarkan bagaimana Direct Lake pada kueri SQL dievaluasi (dan apakah mereka gagal). Manfaat mode penyimpanan Direct Lake hanya dimungkinkan ketika langkah kelima tercapai.

1. Jika kueri berisi tabel atau kolom apa pun yang dibatasi oleh OLS pada model semantik, dihasilkan sebagai kesalahan (visualisasi laporan gagal dirender).
2. Jika kueri berisi kolom apa pun yang dibatasi oleh titik akhir analitik SQL CLS (atau tabel ditolak), akan menghasilkan kesalahan (visual laporan tidak dapat dihasilkan).
   1. Jika koneksi cloud menggunakan SSO (default), CLS ditentukan oleh tingkat akses konsumen laporan.
   2. Jika koneksi cloud menggunakan identitas tetap, CLS ditentukan oleh tingkat akses identitas tetap.
3. Jika model semantik menggunakan Direct Lake pada titik akhir SQL dan kueri berisi tabel apa pun di titik akhir analitik SQL yang memberlakukan RLS atau tampilan digunakan, kueri akan kembali ke mode DirectQuery.
   1. Jika koneksi cloud menggunakan SSO (default), RLS ditentukan oleh tingkat akses konsumen laporan.
   2. Jika koneksi cloud menggunakan identitas tetap, RLS ditentukan oleh tingkat akses identitas tetap.
4. Jika kueri melebihi pagar pembatas kapasitas, kueri akan kembali ke mode DirectQuery.
5. Jika tidak, kueri terpenuhi dari cache dalam memori. Data kolom dimuat ke dalam memori jika diperlukan.

Penting

Direct Lake di OneLake tidak mendukung fallback ke mode DirectQuery. Jika ada tabel di endpoint analitik SQL yang memberlakukan RLS atau kueri melebihi batas kapasitas, akan mengembalikan hasil kesalahan (visual laporan tidak dapat ditampilkan).

Opsi aturan akses data

Anda dapat menyiapkan aturan akses data di:

• Model semantik.
• Titik akhir analitik SQL (Direct Lake hanya untuk titik akhir SQL).
• Keamanan OneLake.

Aturan dalam model semantik

Jika Anda harus menerapkan aturan akses data, Anda harus melakukannya dalam keamanan OneLake sehingga aturan berlaku di semua mesin komputasi dan memastikan kontrol akses terpadu untuk pengguna. Gunakan model semantik RLS atau OLS saat konsumen laporan tidak diberikan izin untuk mengakses lakehouse atau gudang data, dan koneksi awan menggunakan identitas tetap alih-alih SSO. SSO menyiratkan bahwa pengguna akhir dapat mengakses sumber data secara langsung dan karenanya mungkin melewati aturan keamanan dalam model semantik.

Penting

Izin item model semantik dapat diatur secara eksplisit melalui aplikasi Power BI, atau diperoleh secara implisit melalui peran ruang kerja.

Terutama, aturan akses data model semantik tidak diberlakukan untuk pengguna yang memiliki izin Tulis pada model semantik. Sebaliknya, aturan akses data berlaku untuk pengguna yang ditugaskan peran Penampil ruang kerja. Namun, pengguna yang ditetapkan ke peran ruang kerja Admin, Anggota, atau Kontributor secara implisit memiliki izin Tulis pada model semantik sehingga aturan akses data tidak diberlakukan. Untuk informasi selengkapnya, lihat Peran di ruang kerja.

Aturan di beberapa lapisan

Aturan akses data dapat diberlakukan di semua lapisan. Namun, pendekatan ini melibatkan kompleksitas ekstra dan overhead manajemen. Dalam hal ini, disarankan agar koneksi cloud menggunakan identitas tetap alih-alih SSO.

Membandingkan opsi aturan akses data

Tabel berikut membandingkan opsi penyiapan akses data untuk Direct Lake pada titik akhir SQL dan Direct Lake di OneLake.

Menerapkan aturan akses data	Direct Lake pada SQL	Danau Langsung di OneLake	Comment
Hanya model semantik	Dukungan	Dukungan	Gunakan opsi ini ketika pengguna tidak diberikan izin akses untuk meminta data dari lakehouse atau gudang. Siapkan koneksi cloud untuk menggunakan identitas tetap. Performa kueri tinggi dapat dicapai dari cache dalam memori.
Titik akhir analitik SQL saja	Didukung (kembali ke DirectQuery)	Tidak berlaku	Tergantung pada item data Fabric (seperti Lakehouse atau Gudang) menggunakan mode identitas yang didelegasikan. Gunakan opsi ini saat pengguna perlu mengakses data dari gudang atau model semantik, dan dengan aturan akses data yang konsisten. Pastikan SSO diaktifkan untuk koneksi cloud. Performa kueri mungkin lambat karena mekanisme fallback DirectQuery.
Hanya keamanan OneLake	Tidak berlaku	Dukungan	Gunakan opsi ini untuk kontrol akses terpadu di semua mesin komputasi Fabric. Keamanan OneLake memberlakukan OLS dan RLS secara konsisten untuk semua pengguna yang mengakses data melalui jalur apa pun. Performa kueri tinggi dapat dicapai dari cache dalam memori.
Beberapa lapisan (model semantik dan titik akhir SQL)	Dukungan	Tidak berlaku	Opsi ini melibatkan overhead manajemen ekstra. Siapkan koneksi cloud untuk menggunakan identitas tetap.
Beberapa lapisan (model semantik dan keamanan OneLake)	Tidak berlaku	Dukungan	Aturan keamanan OneLake diterapkan terlebih dahulu, lalu aturan model semantik. Pertimbangkan untuk mengonsolidasikan aturan pada satu lapisan untuk mengurangi kompleksitas.

Pertimbangan dan keterbatasan

Pertimbangkan batasan keamanan Direct Lake ini.

Nota

Kemampuan dan fitur model semantik Direct Lake dan keamanan OneLake berkembang dengan cepat. Periksa kembali secara berkala untuk pembaruan.

• Tetapkan peran keamanan OneLake kepada peninjau ruang kerja yang memberikan akses baca ke artefak Fabric sumber. Jika artefak sumber memiliki pintasan ke artefak dari Fabric lainnya, pengguna juga harus memiliki akses baca ke artefak dari Fabric yang menjadi target setiap pintasan.
• Gunakan identitas tetap untuk mengisolasi pengguna dari artefak Fabric sumber. Ikat model Direct Lake ke koneksi cloud. Biarkan SSO dinonaktifkan pada koneksi cloud untuk menggunakan identitas tetap dalam melakukan refresh dan kueri.
• Model semantik Direct Lake yang mengandalkan keamanan Fabric OneLake pada artefak sumber tidak mendukung operasi pencadangan.
• Hubungan dua arah tidak didukung dalam model Direct Lake jika artefak Fabric sumber bergantung pada RLS keamanan OneLake.
• Keamanan OneLake tidak mendukung definisi dinamis atau konfigurasi peran kompleks, seperti menggabungkan beberapa peran OLS dan RLS di seluruh tabel terkait.
• Mengonsolidasikan izin RLS dan OLS keamanan OneLake ke dalam satu peran per pengguna alih-alih menetapkan beberapa peran.
• Jika konfigurasi keamanan OneLake berubah, seperti karena perubahan pintasan dalam artefak target, refresh Direct Lake pada model OneLake yang mengakses artefak tersebut. Anda harus merefresh model secara manual atau dengan menggunakan API refresh.
• Jika sebuah Lakehouse memiliki keamanan OneLake:
  • Titik akhir analitik SQL, secara default, memiliki identitas tetap diatur kepada pemilik Lakehouse, sehingga keamanan titik akhir analitik SQL OneLake sama dengan pemiliknya (tanpa batasan). Direct Lake di SQL tetap menggunakan Direct Lake, kecuali ditambahkan peran akses SQL granular tambahan.
  • Titik akhir analitik SQL dapat diubah ke SSO. Ketika ini terjadi, peran keamanan OneLake ditambahkan sebagai aturan kontrol akses terperinci SQL dan pengguna diblokir untuk mengeditnya langsung di titik akhir analitik SQL. Pada saat ini, Direct Lake di SQL secara otomatis beralih ke DirectQuery 100% setiap saat.