Bagikan melalui

Keamanan OneLake untuk titik akhir analitik SQL (Pratinjau)

Dengan keamanan OneLake, Microsoft Fabric memperluas cara organisasi dapat mengelola dan menerapkan akses data di seluruh beban kerja. Kerangka kerja keamanan baru ini memberi administrator fleksibilitas yang lebih besar untuk mengonfigurasi izin. Administrator dapat memilih antara tata kelola terpusat melalui OneLake atau kontrol berbasis SQL terperinci dalam titik akhir analitik SQL.

Mode akses di titik akhir analitik SQL

Saat menggunakan titik akhir analitik SQL, mode akses yang dipilih menentukan bagaimana keamanan data diberlakukan. Fabric mendukung dua model akses yang berbeda, masing-masing menawarkan manfaat yang berbeda tergantung pada kebutuhan operasional dan kepatuhan Anda:

  • Mode identitas pengguna: Memberlakukan keamanan menggunakan peran dan kebijakan OneLake. Dalam mode ini, titik akhir analitik SQL meneruskan identitas pengguna yang masuk ke OneLake, dan akses baca diatur sepenuhnya oleh aturan keamanan yang ditentukan dalam OneLake. Izin tingkat SQL pada tabel didukung, memastikan tata kelola yang konsisten di seluruh alat seperti Power BI, notebook, dan lakehouse.

  • Mode identitas yang didelegasikan: Menyediakan kontrol penuh melalui SQL. Dalam mode ini, titik akhir analitik SQL terhubung ke OneLake menggunakan identitas ruang kerja atau pemilik item , dan keamanan diatur secara eksklusif oleh izin SQL yang ditentukan di dalam database. Model ini mendukung pendekatan keamanan tradisional termasuk GRANT, REVOKE, peran kustom, Row-Level Security, dan Dynamic Data Masking.

Setiap mode mendukung model tata kelola yang berbeda. Memahami implikasi mereka sangat penting untuk memilih pendekatan yang tepat di lingkungan Fabric Anda.

Perbandingan antara mode akses

Berikut adalah tabel perbandingan yang jelas dan ringkas yang berfokus pada cara dan tempat Anda mengatur keamanan dalam mode identitas pengguna versus mode identitas yang didelegasikan—dipecah berdasarkan jenis objek dan kebijakan akses data:

Target keamanan Mode identitas pengguna Mode identitas yang didelegasikan
Tables Akses dikendalikan oleh peran keamanan OneLake. SQL GRANT/REVOKE tidak diizinkan. Kontrol penuh menggunakan SQL GRANT/REVOKE.
Views Gunakan SQL GRANT/REVOKE untuk menetapkan izin. Gunakan SQL GRANT/REVOKE untuk menetapkan izin.
Prosedur tersimpan Gunakan SQL GRANT EXECUTE untuk menetapkan izin. Gunakan SQL GRANT EXECUTE untuk menetapkan izin.
Fungsi Gunakan SQL GRANT EXECUTE untuk menetapkan izin. Gunakan SQL GRANT EXECUTE untuk menetapkan izin.
Row-Level Security (RLS) Didefinisikan dalam OneLake UI sebagai bagian dari peran keamanan OneLake. Ditentukan menggunakan SQL CREATE SECURITY POLICY.
KeamananColumn-Level (CLS) Didefinisikan dalam OneLake UI sebagai bagian dari peran keamanan OneLake. Ditentukan menggunakan SQL GRANT SELECT dengan daftar kolom.
Masking Data Dinamis (DDM) Tidak didukung dalam keamanan OneLake. Ditentukan menggunakan SQL ALTER TABLE dengan MASKED opsi.

Mode identitas pengguna dalam keamanan OneLake

Dalam mode identitas pengguna, titik akhir analitik SQL menggunakan mekanisme autentikasi passthrough untuk menerapkan akses data. Saat pengguna terhubung ke titik akhir analitik SQL, identitas ID Entra mereka diteruskan ke OneLake, yang melakukan pemeriksaan izin. Semua operasi baca terhadap tabel dievaluasi menggunakan aturan keamanan yang ditentukan dalam OneLake Lakehouse, bukan oleh pernyataan GRANT atau REVOKE tingkat SQL.

Mode ini memungkinkan Anda mengelola keamanan secara terpusat, memastikan penegakan yang konsisten di semua pengalaman Fabric, termasuk Power BI, notebook, lakehouse, dan titik akhir analitik SQL. Ini dirancang untuk model tata kelola di mana akses harus ditentukan sekali di OneLake dan secara otomatis dihormati di mana-mana.

Dalam mode identitas pengguna:

  • Akses tabel diatur sepenuhnya oleh keamanan OneLake. Pernyataan SQL GRANT/REVOKE pada tabel diabaikan.

  • RLS (Row-Level Security), CLS (Column-Level Security), dan Object-Level Security semuanya ditentukan dalam pengalaman OneLake.

  • Izin SQL diizinkan untuk objek nondata seperti tampilan, prosedur tersimpan, dan fungsi, memungkinkan fleksibilitas untuk menentukan logika kustom atau titik masuk yang menghadap pengguna ke data.

  • Operasi tulis tidak didukung di titik akhir analitik SQL. Semua penulisan harus terjadi melalui UI Lakehouse dan diatur oleh peran ruang kerja (Admin, Anggota, Kontributor).

Penting

Titik akhir Analitik SQL memerlukan pemetaan satu-ke-satu antara izin item dan anggota dalam peran keamanan OneLake agar dapat disinkronkan dengan benar. Jika Anda memberikan akses identitas ke peran keamanan OneLake, maka identitas tersebut juga harus memiliki izin Fabric Read untuk lakehouse. Misalnya, jika pengguna menetapkan "user123@microsoft.com" ke peran keamanan OneLake, maka "user123@microsoft.com" juga harus ditetapkan ke lakehouse tersebut.

Perilaku peran ruang kerja

Pengguna dengan peran Admin, Anggota, atau Kontributor di tingkat ruang kerja tidak tunduk pada penegakan keamanan OneLake. Peran ini memiliki hak istimewa yang ditingkatkan dan akan melewati kebijakan RLS, CLS, dan OLS sepenuhnya. Ikuti persyaratan ini untuk memastikan keamanan OneLake dihormati:

  • Menetapkan peran Penampil kepada pengguna di ruang kerja, atau

  • Bagikan titik akhir analitik Lakehouse atau SQL dengan pengguna menggunakan izin baca-saja . Hanya pengguna dengan akses baca-saja yang memiliki kueri mereka yang difilter sesuai dengan peran keamanan OneLake.

Prioritas peran: Akses paling permisif menang

Jika pengguna termasuk dalam beberapa peran OneLake, peran yang paling permisif menentukan akses efektif mereka. Contohnya:

  • Jika satu peran memberikan akses penuh ke tabel dan peran lain menerapkan RLS untuk membatasi baris, RLS tidak akan diberlakukan.

  • Peran akses yang lebih luas lebih diutamakan. Perilaku ini memastikan pengguna tidak diblokir secara tidak sengaja, tetapi memerlukan desain peran yang cermat untuk menghindari konflik. Disarankan untuk menjaga peran pembatasan dan permisif saling eksklusif saat memberlakukan kontrol akses tingkat baris atau kolom.

Untuk informasi selengkapnya, lihat model kontrol akses data untuk keamanan OneLake.

Sinkronisasi keamanan antara oneLake dan titik akhir analitik SQL

Komponen penting dari mode identitas pengguna adalah layanan sinkronisasi keamanan. Layanan latar belakang ini memantau perubahan yang dilakukan pada peran keamanan di OneLake dan memastikan perubahan tersebut tercermin dalam titik akhir analitik SQL.

Layanan sinkronisasi keamanan bertanggung jawab atas hal berikut:

  • Mendeteksi perubahan pada peran OneLake, termasuk peran baru, pembaruan, penetapan pengguna, dan perubahan pada tabel.

  • Menerjemahkan kebijakan yang ditentukan OneLake (RLS, CLS, OLS) ke dalam struktur peran database yang kompatibel dengan SQL yang setara.

  • Memastikan objek pintasan (tabel yang bersumber dari lakehouse lain) divalidasi dengan benar sehingga pengaturan keamanan OneLake asli dihormati, bahkan ketika diakses dari jarak jauh.

Sinkronisasi ini memastikan bahwa definisi keamanan OneLake tetap otoritatif, menghilangkan kebutuhan intervensi tingkat SQL manual untuk mereplikasi perilaku keamanan. Karena keamanan diberlakukan secara terpusat:

  • Anda tidak dapat menentukan RLS, CLS, atau OLS secara langsung menggunakan T-SQL dalam mode ini.

  • Anda masih dapat menerapkan izin SQL ke tampilan, fungsi, dan prosedur tersimpan menggunakan pernyataan GRANT atau EXECUTE.

Kesalahan & resolusi sinkronisasi keamanan

Scenario Perilaku dalam mode identitas pengguna Perilaku dalam mode yang didelegasikan Tindakan korektif Catatan
Kebijakan RLS mereferensikan kolom yang dihapus atau diganti namanya Kesalahan: *Kebijakan keamanan tingkat baris mereferensikan kolom yang sudah tidak ada lagi.*Database memasukkan status kesalahan hingga kebijakan diperbaiki. Kesalahan: Nama kolom nama <kolom tidak valid> Perbarui atau hapus satu atau beberapa peran yang terpengaruh, atau pulihkan kolom yang hilang. Pembaruan perlu dilakukan di lakehouse tempat peran tersebut dibuat.
Kebijakan CLS mereferensikan kolom yang dihapus atau diganti namanya Kesalahan: *Kebijakan keamanan tingkat kolom mereferensikan kolom yang sudah tidak ada lagi.*Database memasukkan status kesalahan hingga kebijakan diperbaiki. Kesalahan: Nama kolom nama <kolom tidak valid> Perbarui atau hapus satu atau beberapa peran yang terpengaruh, atau pulihkan kolom yang hilang. Pembaruan perlu dilakukan di lakehouse tempat peran tersebut dibuat.
Kebijakan RLS/CLS mereferensikan tabel yang dihapus atau diganti namanya Kesalahan: Kebijakan keamanan mereferensikan tabel yang sudah tidak ada lagi. Tidak ada kesalahan yang muncul; kueri gagal secara diam-diam jika tabel hilang. Perbarui atau hapus satu atau beberapa peran yang terpengaruh, atau pulihkan tabel yang hilang. Pembaruan perlu dilakukan di lakehouse tempat peran tersebut dibuat.
Kebijakan DDM (Masking Data Dinamis) mereferensikan kolom yang dihapus atau diganti namanya DDM yang tidak didukung dari OneLake Security, harus diimplementasikan melalui SQL. Kesalahan: Nama kolom nama <kolom tidak valid> Perbarui atau hapus satu atau beberapa aturan DDM yang terpengaruh, atau pulihkan kolom yang hilang. Perbarui kebijakan DDM di Titik Akhir Analitik SQL.
Kesalahan sistem (kegagalan tak terduga) Kesalahan: Terjadi kesalahan sistem yang tidak terduga. Coba lagi atau hubungi dukungan. Kesalahan: Terjadi kesalahan internal saat menerapkan perubahan tabel ke SQL. Coba lagi operasi; jika masalah berlanjut, hubungi Dukungan Microsoft. N/A
Pengguna tidak memiliki izin pada artefak Kesalahan: Pengguna tidak memiliki izin pada artefak Kesalahan: Pengguna tidak memiliki izin pada artefak Berikan pengguna izin objectID {objectID} ke artefak. ID objek harus sama persis antara anggota peran keamanan OneLake dan izin item Fabric. Jika grup ditambahkan ke keanggotaan peran, maka grup yang sama tersebut harus diberi izin Fabric Read. Menambahkan anggota dari grup tersebut ke item tidak dihitung sebagai kecocokan langsung.
Pengguna utama tidak didukung. Kesalahan: User principal tidak didukung. Kesalahan: User principal tidak didukung. Hapus pengguna {username} dari peran DefaultReader Kesalahan ini terjadi jika pengguna tidak lagi menjadi ID Entra yang valid, seperti jika pengguna telah meninggalkan organisasi Anda atau telah dihapus. Untuk mengatasi kesalahan ini, hapus mereka dari peran.

Perilaku pintasan dengan sinkronisasi keamanan

Keamanan OneLake diberlakukan pada sumber kebenaran, sehingga sinkronisasi keamanan menonaktifkan rantai kepemilikan untuk tabel dan tampilan yang melibatkan pintasan. Ini memastikan bahwa izin sistem sumber selalu dievaluasi dan dihormati, bahkan untuk kueri dari database lain.

Akibatnya:

  • Pengguna harus memiliki akses yang valid padasumber pintasan (titik akhir analitik Lakehouse atau SQL saat ini) dantujuan tempat data berada secara fisik.

  • Jika pengguna tidak memiliki izin di kedua sisi, kueri akan gagal dengan kesalahan akses.

  • Saat merancang aplikasi atau tampilan yang mereferensikan pintasan, pastikan bahwa penetapan peran dikonfigurasi dengan benar di kedua akhir hubungan pintasan.

Desain ini mempertahankan integritas keamanan di seluruh batas Lakehouse, tetapi memperkenalkan skenario di mana kegagalan akses mungkin terjadi jika peran lintas Lakehouse tidak selaras.

Mode yang didelegasikan dalam keamanan OneLake

Dalam Mode Identitas yang Didelegasikan, titik akhir analitik SQL menggunakan model keamanan yang sama yang ada saat ini di Microsoft Fabric. Keamanan dan izin dikelola sepenuhnya di lapisan SQL, dan peran OneLake atau kebijakan akses tidak diberlakukan untuk akses tingkat tabel. Saat pengguna tersambung ke titik akhir analitik SQL dan mengeluarkan kueri:

  • SQL memvalidasi akses berdasarkan izin SQL (GRANT, REVOKE, RLS, CLS, DDM, peran, dll.).

  • Jika kueri diotorisasi, sistem melanjutkan untuk mengakses data yang disimpan di OneLake.

  • Akses data ini dilakukan menggunakan identitas pemilik titik akhir analitik Lakehouse atau SQL—juga dikenal sebagai akun item.

Dalam model ini:

  • Pengguna yang masuk tidak diteruskan ke OneLake.

  • Semua penerapan akses diasumsikan ditangani di lapisan SQL.

  • Pemilik item bertanggung jawab untuk memiliki izin yang memadai di OneLake untuk membaca file yang mendasar atas nama beban kerja.

Karena ini adalah pola yang didelegasikan, ketidakselarasan antara izin SQL dan akses OneLake untuk pemilik mengakibatkan kegagalan kueri. Mode ini memberikan kompatibilitas penuh dengan:

  • SQL GRANT/REVOKE di semua tingkat objek

  • KeamananRow-Level yang ditentukan SQL, KeamananColumn-Level, dan Masking Data Dinamis

  • Alat dan praktik T-SQL yang ada yang digunakan oleh DBA atau aplikasi

Cara mengubah mode akses OneLake

Mode akses menentukan bagaimana akses data diautentikasi dan diberlakukan saat mengkueri OneLake melalui titik akhir analitik SQL. Anda dapat beralih antara mode identitas pengguna dan mode identitas yang didelegasikan menggunakan langkah-langkah berikut:

  1. Navigasi ke ruang kerja Fabric Anda dan buka lakehouse Anda. Dari sudut kanan atas, beralih dari lakehouse ke titik akhir analitik SQL.

  2. Dari navigasi atas, buka tab Keamanan dan pilih salah satu mode akses OneLake berikut ini:

    • Identitas pengguna – Menggunakan identitas pengguna yang masuk. Ini memberlakukan peran OneLake.

    • Identitas yang didelegasikan – Menggunakan identitas pemilik item; hanya memberlakukan izin SQL.

  3. Pop-up diluncurkan untuk mengonfirmasi pilihan Anda. Pilih Ya untuk mengonfirmasi perubahan.

Pertimbangan saat beralih antar mode

Penting

Beralih antara Identitas Pengguna dan mode yang Didelegasikan (di kedua arah) saat ini menghapus objek metadata sebaris, termasuk TVF dan fungsi Scalar-Valued. Perilaku ini hanya memengaruhi definisi metadata; data yang mendasar di OneLake tidak terpengaruh.

Beralih ke mode identitas pengguna

  • Izin tingkat tabel, CLS, dan RLS SQL diabaikan.

  • Peran OneLake harus dikonfigurasi agar pengguna dapat mempertahankan akses.

  • Hanya pengguna dengan izin Penampil atau akses baca-saja bersama yang akan diatur oleh keamanan OneLake.

  • Peran SQL yang ada dihapus dan tidak dapat dipulihkan.

Beralih ke mode identitas yang didelegasikan

  • Peran OneLake dan kebijakan keamanan tidak lagi diterapkan.

  • Peran SQL dan kebijakan keamanan menjadi aktif.

  • Pemilik item harus memiliki akses OneLake yang valid, atau semua kueri mungkin gagal.

Keterbatasan

  • Hanya berlaku untuk pembaca: OneLake Security mengatur pengguna yang mengakses data sebagai Pemirsa. Pengguna dalam peran ruang kerja lain (Anggota Admin, atau Kontributor) melewati OneLake Security dan mempertahankan akses penuh.

  • Objek SQL tidak mewarisi kepemilikan: Pintasan muncul di titik akhir analitik SQL sebagai tabel. Saat mengakses tabel ini, secara langsung atau melalui tampilan, prosedur tersimpan, dan objek SQL turunan lainnya tidak membawa kepemilikan tingkat objek; semua izin diperiksa pada runtime untuk mencegah bypass keamanan.

  • Perubahan pintasan memicu waktu henti validasi: Saat target pintasan berubah (misalnya, mengganti nama, pembaruan URL), database memasuki mode pengguna tunggal secara singkat saat sistem memvalidasi target baru. Selama periode ini kueri diblokir, operasi ini cukup cepat, tetapi terkadang tergantung pada proses internal yang berbeda dapat memakan waktu hingga 5 menit untuk disinkronkan.

    • Membuat pintasan skema dapat menyebabkan kesalahan yang diketahui yang memengaruhi validasi dan penundaan sinkronisasi metadata.

  • Penyebaran izin tertunda: Perubahan izin tidak seketika. Beralih antara mode keamanan (Identitas Pengguna vs. Didelegasikan) mungkin memerlukan waktu untuk menyebar sebelum berlaku, tetapi harus memakan waktu kurang dari 1 menit.

  • Dependensi sarana kontrol: Izin tidak dapat diterapkan ke pengguna atau grup yang belum ada di sarana kontrol ruang kerja. Anda harus berbagi item sumber, atau pengguna harus menjadi anggota peran ruang kerja Penampil. Perhatikan bahwa ID objek yang sama persis harus berada di kedua tempat. Grup dan anggota grup tersebut tidak dihitung sebagai kecocokan.

  • Akses paling permisif berlaku: Ketika pengguna termasuk dalam beberapa grup atau peran, izin efektif yang paling permisif adalah Contoh yang dihormati: Jika pengguna memiliki TOLAK melalui satu peran dan GRANT melalui yang lain, GRANT lebih diutamakan.

  • Batasan mode yang didelegasikan: Dalam mode Didelegasikan, sinkronisasi metadata pada tabel pintasan dapat gagal jika item sumber memiliki kebijakan Keamanan OneLake yang tidak memberikan akses tabel penuh kepada pemilik item.

  • Perilaku TOLAK: Saat beberapa peran berlaku untuk satu tabel pintasan, persimpangan izin mengikuti semantik SQL Server: TOLAK mengambil alih GRANT. Ini dapat menghasilkan hasil akses yang tidak terduga.

  • Kondisi kesalahan yang diharapkan: Pengguna mungkin mengalami kesalahan dalam skenario seperti:

    • Target pintasan diganti namanya atau tidak valid

      • Contoh: Jika sumber tabel dihapus.

    • Kesalahan konfigurasi RLS (Row-Level Security)

      • Beberapa ekspresi untuk pemfilteran RLS tidak didukung di OneLake dan mungkin mengizinkan akses data yang tidak sah.

      • Menjatuhkan kolom yang digunakan pada ekspresi filter membatalkan Sinkronisasi RLS dan Metadata akan usang hingga RLS diperbaiki pada Panel Keamanan OneLake.

      • Untuk Pratinjau Umum, kami hanya mendukung tabel ekspresi tunggal. RLS dinamis dan RLS Multi-Tabel tidak didukung saat ini.

    • Batasan Column-Level Security (CLS)

      • CLS bekerja dengan mempertahankan daftar kolom yang diizinkan. Jika kolom yang diizinkan dihapus atau diganti namanya, kebijakan CLS menjadi tidak valid.

      • Ketika CLS tidak valid, sinkronisasi metadata diblokir hingga aturan CLS diperbaiki di panel OneLake Security.

    • Kegagalan sinkronisasi metadata atau izin

      • Jika ada perubahan pada tabel, seperti mengganti nama kolom, keamanan tidak direplikasi pada objek baru, dan Anda menerima kesalahan UI yang menunjukkan bahwa kolom tidak ada.

  • Penggantian nama tabel tidak mempertahankan kebijakan keamanan: Jika peran OneLake Security (OLS) ditentukan pada tingkat Skema, peran tersebut tetap berlaku hanya selama nama tabel tidak berubah. Mengganti nama tabel akan merusak asosiasi, dan kebijakan keamanan tidak akan dimigrasikan secara otomatis. Ini dapat mengakibatkan paparan data yang tidak diinginkan sampai kebijakan diterapkan kembali.

  • Peran keamanan OneLake tidak boleh memiliki nama yang lebih panjang dari 124 karakter; jika tidak, sinkronisasi keamanan tidak dapat menyinkronkan peran.

  • Peran keamanan OneLake disebarkan pada titik akhir analitik SQL dengan awalan OLS_.

  • Perubahan pengguna pada peran OLS_ tidak didukung, dan dapat menyebabkan perilaku tak terduga.

  • Grup keamanan yang diaktifkan email dan daftar distribusi tidak didukung.

  • Pemilik lakehouse harus menjadi anggota peran admin, anggota, atau ruang kerja kontributor; jika tidak, keamanan tidak diterapkan ke titik akhir analitik SQL.

  • Pemilik lakehouse tidak dapat menjadi prinsipal layanan agar sinkronisasi keamanan dapat berfungsi dengan baik.

Konten terkait

  • Last updated on