Keamanan tingkat baris (RLS) dengan Power BI

Keamanan tingkat baris (RLS) membatasi akses data untuk pengguna tertentu dari model semantik Power BI. Filter membatasi data di tingkat baris, dan Anda menentukan filter dalam peran. Di layanan Power BI, pengguna dengan akses ke ruang kerja memiliki akses ke model semantik di ruang kerja tersebut. RLS hanya membatasi akses data untuk pengguna dengan izin Penampil . Ini tidak berlaku untuk peran Admin, Anggota, atau Kontributor ruang kerja.

Untuk menerapkan RLS, ikuti alur kerja tingkat tinggi ini:

  1. Define peran dan aturan di Power BI Desktop menggunakan ekspresi filter DAX.
  2. Publish model semantik dan laporkan ke layanan Power BI.
  3. Tambahkan anggota ke peran dalam layanan Power BI.
  4. Validasi dengan menggunakan fitur Uji sebagai peran untuk mengonfirmasi pemfilteran data berfungsi seperti yang diharapkan.

Anda dapat mengonfigurasi RLS untuk model semantik yang diimpor di Power BI Desktop atau layanan Power BI. Anda juga dapat mengonfigurasi RLS pada model semantik yang menggunakan DirectQuery, seperti SQL Server. Untuk koneksi langsung Analysis Services atau Azure Analysis Services, Anda mengonfigurasi keamanan tingkat baris dalam model, bukan di Power BI. Opsi keamanan tidak muncul untuk model semantik koneksi langsung.

Catatan

Artikel ini membahas RLS untuk model semantik Power BI secara khusus. Untuk keamanan data di item Microsoft Fabric lainnya, lihat Keamanan di Microsoft Fabric.

Catatan

Untuk model semantik Direct Lake di Microsoft Fabric, RLS didukung. Namun, jika kueri DAX kembali ke mode DirectQuery karena fitur yang tidak didukung, filter RLS masih berlaku tetapi karakteristik performa dapat berubah. Pantau perilaku fallback dari kueri di aplikasi metrik kapasitas Fabric.

Menentukan peran dan aturan dalam Power BI Desktop

Anda dapat menentukan peran dan aturan dalam Power BI Desktop. Dengan editor ini, Anda dapat beralih antara menggunakan antarmuka drop-down default dan antarmuka DAX. Saat menerbitkan ke Power BI, Anda juga menerbitkan definisi peran.

Untuk menentukan peran keamanan:

  1. Impor data ke dalam laporan Power BI Desktop Anda, atau konfigurasikan koneksi DirectQuery.

    Catatan

    Anda tidak dapat menentukan peran untuk koneksi langsung Analysis Services di Power BI Desktop. Anda perlu melakukannya dalam model Analysis Services.

  2. Dari tab Pemodelan , pilih Kelola Peran.

  3. Dari jendela Kelola peran, pilih Baru untuk membuat peran baru.

  4. Di bawah Peran, berikan nama untuk peran tersebut dan pilih masukkan.

    Catatan

    Anda tidak dapat menentukan peran dengan koma, misalnya London,ParisRole.

  5. Di bawah Pilih tabel, pilih tabel yang ingin Anda terapkan filter keamanan tingkat baris.

  6. Di bawah Filter data, gunakan editor default untuk mendefinisikan peran Anda. Ekspresi yang dibuat mengembalikan nilai benar atau salah. Filter DAX mengevaluasi TRUE/FALSE untuk setiap baris. Hanya baris yang mengembalikan TRUE yang terlihat. Semua yang lain sepenuhnya dihapus.

    Catatan

    Tidak semua filter keamanan tingkat baris yang didukung di Power BI dapat ditentukan menggunakan editor default. Batasan mencakup ekspresi yang saat ini hanya dapat ditentukan menggunakan DAX termasuk aturan dinamis seperti username() atau userprincipalname(). Untuk menentukan peran menggunakan filter ini beralih untuk menggunakan editor DAX.

  7. Secara opsional pilih Beralih ke editor DAX untuk beralih menggunakan editor DAX untuk menentukan peran Anda. Ekspresi DAX menghasilkan hasil true atau false. Misalnya: [Entity ID] = “Value”. Editor DAX dilengkapi dengan pelengkapan otomatis untuk rumus (intellisense). Anda dapat memilih tanda centang di atas kotak ekspresi untuk memvalidasi ekspresi dan tombol X di atas kotak ekspresi untuk mengembalikan perubahan.

    Catatan

    Anda dapat menggunakan nama pengguna() dalam ekspresi ini. Ketahuilah bahwa nama pengguna() memiliki format DOMAIN\username dalam Power BI Desktop. Dalam layanan Power BI dan Power BI Report Server, itu dalam format Nama Prinsipal Pengguna (UPN) pengguna. Selain itu, dalam kotak ekspresi ini, gunakan koma untuk memisahkan argumen fungsi DAX meskipun Anda menggunakan lokal yang biasanya menggunakan pemisah titik koma, seperti Prancis atau Jerman.

  8. Anda dapat beralih kembali ke editor default dengan memilih Beralih ke editor default. Semua perubahan yang dilakukan di salah satu antarmuka editor tetap ada saat mengganti antarmuka jika memungkinkan. Saat menentukan peran menggunakan editor DAX yang tidak dapat ditentukan di editor default, jika Anda mencoba beralih ke editor default, Anda akan diminta dengan peringatan bahwa beralih editor dapat mengakibatkan beberapa informasi hilang. Untuk menyimpan informasi ini, pilih Batal dan lanjutkan mengedit hanya peran ini di editor DAX.

    Catatan

    Dalam kotak ekspresi ini, gunakan koma untuk memisahkan argumen fungsi DAX meskipun Anda menggunakan lokal yang biasanya menggunakan pemisah titik koma, seperti Prancis atau Jerman.

  9. Pilih Simpan.

Anda tidak dapat menetapkan pengguna ke peran dalam Power BI Desktop. Anda menetapkan peran mereka di layanan Power BI. Anda dapat mengaktifkan keamanan dinamis dalam Power BI Desktop dengan menggunakan fungsi DAX username() atau userprincipalname() dan memiliki hubungan yang tepat yang dikonfigurasi.

Pola filter DAX umum untuk peran RLS

Contoh berikut menunjukkan ekspresi filter DAX umum yang dapat Anda gunakan saat menentukan peran RLS di Power BI Desktop:

  • RLS statis — Membatasi data ke nilai tetap:

    [Region] = "West"

  • RLS dinamis dengan UPN — Membatasi data berdasarkan alamat email pengguna yang masuk:

    [UserEmail] = USERPRINCIPALNAME()

  • RLS dinamis dengan USERNAME — Membatasi data berdasarkan domain dan nama pengguna pengguna:

    [UserDomain] = USERNAME()

  • RLS Dinamis dengan CUSTOMDATA — Membatasi data berdasarkan string kustom yang diteruskan dari aplikasi embed:

    [AppRole] = CUSTOMDATA()

    Catatan

    CUSTOMDATA() terutama digunakan dalam skenario yang disematkan di mana aplikasi meneruskan string identitas efektif kustom melalui REST API Power BI.

RLS Dinamis adalah pendekatan yang paling umum karena memungkinkan definisi peran tunggal untuk memfilter data secara berbeda untuk setiap pengguna, berdasarkan tabel pemetaan pengguna dalam model data Anda.

Contoh: Memfilter Power BI data penjualan menurut wilayah

Misalkan Anda memiliki Sales tabel dengan kolom Region, Product, dan Amount. Anda ingin membatasi pengguna yang ditetapkan ke peran "Barat" sehingga mereka hanya melihat baris di mana wilayah tersebut adalah "Barat".

Di bidang filter DAX untuk peran "Barat", masukkan ekspresi berikut:

[Region] = "West"

Sebelum memfilter (semua data):

Wilayah Produk Jumlah
Barat Widget A 500
Timur Widget B 300
Barat Widget C 450
Selatan Widget A 200
Timur Widget C 375

Setelah pemfilteran (tampilan untuk pengguna peran "Barat"):

Wilayah Produk Jumlah
Barat Widget A 500
Barat Widget C 450

Ekspresi DAX bertindak sebagai filter baris yang mengevaluasi setiap baris dalam tabel. Hanya baris dengan nilai kolom Region "West" yang terlihat oleh pengguna yang ditetapkan ke peran tersebut.

Petunjuk / Saran

Gunakan fitur Tampilkan sebagai peran (dijelaskan dalam Memvalidasi peran dalam layanan Power BI) untuk memvalidasi bahwa filter Anda mengembalikan baris yang diharapkan sebelum menerbitkan laporan.

Pemfilteran silang dua arah dengan RLS

Secara default, pemfilteran keamanan tingkat baris menggunakan filter arah tunggal, apakah hubungan diatur ke arah tunggal atau dua arah.

Anda dapat mengaktifkan pemfilteran silang dua arah secara manual dengan keamanan tingkat baris dengan memilih hubungan dan mencentang kotak centang Terapkan filter keamanan di kedua arah. Pilih opsi ini saat Anda juga telah menerapkan keamanan tingkat baris dinamis di tingkat server, di mana keamanan tingkat baris didasarkan pada nama pengguna atau ID masuk. Jika tabel mengambil bagian dalam beberapa hubungan dua arah, Anda hanya dapat memilih opsi ini untuk salah satu hubungan tersebut.

Caution

Mengaktifkan pemfilteran keamanan dua arah dapat berdampak negatif pada performa kueri, terutama dalam model dengan banyak hubungan atau himpunan data besar. Uji secara menyeluruh sebelum menyebarkan ke produksi.

Untuk informasi selengkapnya, lihat artikel teknis Pemfilteran silang Dua Arah menggunakan DirectQuery di Power BI dan artikel teknis tentang keamanan untuk Model Semantik BI Tabular.

Cuplikan layar pengaturan hubungan model untuk menerapkan filter keamanan di kedua arah.

Mengelola keamanan pada model semantik Anda

Untuk mengelola keamanan pada model semantik Anda, buka ruang kerja tempat Anda menyimpan model semantik di Microsoft Fabric dan lakukan langkah-langkah berikut:

  1. Di Microsoft Fabric, pilih menu Opsi lainnya untuk model semantik. Menu ini muncul saat Anda mengarahkan mouse ke nama model semantik.

    Cuplikan layar memperlihatkan menu Opsi lainnya di menu navigasi.

  2. Pilih Keamanan.

    Cuplikan layar memperlihatkan menu Opsi lainnya dengan Keamanan dipilih.

Keamanan membawa Anda ke halaman keamanan Row-Level tempat Anda menambahkan anggota ke peran yang Anda buat. Pengguna dengan peran Kontributor di ruang kerja atau yang lebih tinggi dapat melihat opsi Keamanan dan dapat menetapkan peran kepada pengguna. Kepemilikan model semantik atau izin Build mungkin juga diperlukan tergantung pada skenarionya.

Catatan

Anda hanya dapat mengelola keamanan pada model semantik yang memiliki peran keamanan tingkat baris yang sudah ditentukan di Power BI Desktop atau saat mengedit model data Anda di layanan Power BI. Jika model semantik Anda belum memiliki peran yang sudah ditentukan, Anda tidak dapat mengelola keamanan di layanan Power BI.

Mengelola keanggotaan peran RLS di layanan Power BI

Tambahkan anggota ke peran RLS

Di layanan Power BI, Anda dapat menambahkan anggota ke peran RLS dengan mengetikkan alamat email atau nama pengguna atau grup keamanan. Anda tidak dapat menambahkan grup yang dibuat di Power BI. Anda bisa menambahkan anggota di luar organisasi Anda. Untuk panduan tentang cara kerja RLS dengan pengguna tamu B2B eksternal, lihat Pertimbangan untuk pengguna eksternal (tamu B2B).

Anda bisa menggunakan grup Microsoft Entra ID dan yang mendukung email berikut untuk menyiapkan keamanan tingkat baris:

Important

Kelompok Microsoft 365 tidak didukung dan tidak dapat ditambahkan ke dalam peran RLS apa pun. Jenis grup yang disebutkan di atas saja yang didukung untuk keanggotaan peran RLS.

Cuplikan layar memperlihatkan cara menambahkan anggota.

Anda dapat melihat berapa banyak anggota yang menjadi bagian dari peran berdasarkan angka dalam tanda kurung di samping nama peran, atau di samping Anggota.

Cuplikan layar memperlihatkan anggota dalam peran.

Hapus anggota dari peran RLS

Anda dapat menghapus anggota dengan memilih X di samping namanya.

Cuplikan layar memperlihatkan cara menghapus anggota.

Memvalidasi peran dalam layanan Power BI

Anda dapat memvalidasi bahwa peran RLS yang Anda tentukan berfungsi dengan benar dalam layanan Power BI dengan menguji peran.

  1. Pilih Opsi lainnya (...) di samping peran.
  2. Pilih Test sebagai peran.

Tangkapan layar opsi peran sebagai Uji.

Catatan

Dashboards tidak tersedia untuk pengujian menggunakan opsi Test as role. Anda dialihkan ke laporan yang diterbitkan dari Power BI Desktop dengan model semantik ini, jika ada.

Saat laporan dimuat, verifikasi hal berikut:

  • Laporan hanya menampilkan baris data yang cocok dengan ungkapan filter yang ditentukan oleh peran.
  • Visual, tabel, dan bagan mencerminkan data yang difilter, bukan himpunan data lengkap.
  • Jika Anda menggunakan RLS dinamis, data sesuai dengan identitas yang ditampilkan di tajuk Now viewing as.

Di header halaman, peran yang diterapkan ditampilkan. Uji peran lain, kombinasi peran, atau orang tertentu dengan memilih Sekarang menampilkan sebagai. Di sini Anda melihat detail izin penting yang berkaitan dengan individu atau peran yang sedang diuji. Untuk informasi selengkapnya tentang cara izin berinteraksi dengan RLS, lihat Pengalaman pengguna RLS.

Cuplikan layar Sekarang menampilkan sebagai dropdown untuk orang tertentu.

Uji laporan lain yang tersambung ke model semantik dengan memilih Menampilkan di header halaman. Anda hanya dapat menguji laporan yang terletak di ruang kerja yang sama dengan model semantik Anda.

Cuplikan layar Tampilan untuk memilih laporan lain untuk diuji.

Untuk kembali ke tampilan normal, pilih Kembali ke Keamanan Tingkat Baris.

Catatan

Fitur Test as role tidak berfungsi untuk model semantik DirectQuery yang mengaktifkan single sign-on (SSO). Selain itu, tidak semua aspek laporan dapat divalidasi dalam fitur Uji sebagai peran, termasuk visualisasi T&J, visualisasi wawasan cepat, dan .

Petunjuk / Saran

Jika Pengujian sebagai role tidak menampilkan hasil yang diharapkan, cobalah langkah-langkah berikut:

  • Verifikasi sintaks ekspresi filter DAX sudah benar dan mereferensikan nama kolom yang tepat.
  • Pastikan Anda memilih peran yang benar untuk diuji.
  • Untuk RLS dinamis, konfirmasikan tabel pemetaan pengguna berisi nilai yang cocok untuk USERPRINCIPALNAME() atau USERNAME().
  • Untuk model semantik DirectQuery dengan SSO diaktifkan, Uji sebagai peran tidak didukung. Sebagai gantinya, masuk sebagai pengguna peran Penampil aktual untuk memvalidasi pemfilteran data.

Menggunakan fungsi DAX username() atau userprincipalname()

Anda dapat memanfaatkan fungsi DAX username() atau userprincipalname() dalam himpunan data Anda. Anda dapat menggunakannya dalam ekspresi di Power BI Desktop. Saat Anda menerbitkan model, model tersebut akan digunakan dalam layanan Power BI.

Dalam Power BI Desktop, username() akan mengembalikan pengguna dalam format DOMAIN\User dan userprincipalname() akan mengembalikan pengguna dalam format user@contoso.com.

Dalam layanan Power BI, nama pengguna() dan userprincipalname() keduanya akan mengembalikan Nama Prinsipal Pengguna (UPN) pengguna. Ini terlihat mirip dengan alamat email.

Gunakan RLS dengan ruang kerja di Power BI

Jika Anda menerbitkan laporan Power BI Desktop ke ruang kerja di layanan Power BI, peran RLS diterapkan kepada anggota yang ditetapkan ke peran Penampil di ruang kerja. Bahkan jika Pemirsa diberi izin Build untuk model semantik, RLS masih berlaku. Misalnya, jika Penampil dengan izin Build menggunakan Analisis di Excel, tampilan datanya dibatasi oleh RLS. Anggota ruang kerja yang ditetapkan Admin, Anggota, atau Kontributor memiliki izin edit untuk model semantik dan, oleh karena itu, RLS tidak berlaku untuk mereka. Jika Anda ingin RLS berlaku untuk orang-orang di ruang kerja, Anda hanya dapat menetapkan peran Penampil kepada mereka. Untuk informasi selengkapnya, lihat peran di ruang kerja.

Pertimbangan untuk pengguna eksternal (tamu B2B)

Jika Anda berbagi konten Power BI dengan pengguna eksternal melalui Microsoft Entra B2B, ketahui pertimbangan berikut untuk RLS.

Grup keamanan Microsoft Entra dengan anggota eksternal

Grup keamanan Microsoft Entra yang berisi pengguna tamu B2B eksternal mungkin tidak berfungsi seperti yang diharapkan saat digunakan untuk keanggotaan peran RLS. Dalam beberapa konfigurasi — terutama ketika pengguna eksternal memiliki akun jenis tamu (bukan akun jenis anggota) — keanggotaan grup tamu tidak dievaluasi dengan benar oleh layanan Power BI saat memberlakukan filter RLS.

Solusi yang disarankan: Alih-alih menambahkan pengguna eksternal ke peran RLS melalui grup keamanan Microsoft Entra, tambahkan langsung ke peran melalui alamat email. Alamat email dikaitkan ke akun B2B milik pengguna. Ini memastikan identitas mereka cocok dengan benar saat filter RLS diterapkan. Untuk informasi selengkapnya, lihat Mengelola keanggotaan peran RLS di layanan Power BI.

Untuk organisasi dengan banyak pengguna eksternal, pertimbangkan untuk menggunakan RLS dinamis dengan USERPRINCIPALNAME() alih-alih keanggotaan peran berbasis grup. Pendekatan ini mengevaluasi identitas setiap pengguna satu per satu dan menghindari masalah resolusi keanggotaan grup sepenuhnya.

Important

Jika saat ini Anda menggunakan grup keamanan Microsoft Entra untuk keanggotaan peran RLS dan grup tersebut menyertakan pengguna tamu B2B, verifikasi bahwa pengguna tamu melihat data yang difilter dengan benar. Jika tidak, tambahkan pengguna eksternal secara langsung ke peran RLS berdasarkan alamat email mereka.

Catatan

Cakupan yang tepat dari batasan ini dapat bervariasi tergantung pada konfigurasi Microsoft Entra ID Anda dan jenis undangan tamu B2B yang digunakan. Selalu uji dengan akun pengguna tamu aktual sebelum mengandalkan RLS berbasis grup untuk akses eksternal.

Jika masalah berlanjut setelah menerapkan solusi, lihat Memecahkan masalah: Tamu B2B eksternal tidak melihat data dalam laporan Power BI untuk langkah-langkah diagnostik tambahan.

Resolusi UPN untuk tamu B2B di Power BI RLS

Saat pengguna tamu B2B eksternal mengakses laporan Power BI, fungsi DAX USERPRINCIPALNAME() biasanya mengembalikan pengidentifikasi seperti email (misalnya, user@partner.com). Dalam beberapa konfigurasi, ini mungkin mengembalikan UPN tamu dalam #EXT# format (misalnya, user_partner.com#EXT#@yourtenant.onmicrosoft.com).

Perbedaan ini penting untuk RLS dinamis. Jika tabel pemetaan pengguna Anda menyimpan format pengidentifikasi yang berbeda dari yang USERPRINCIPALNAME() dikembalikan, ekspresi filter tidak akan cocok, dan pengguna tamu mungkin tidak melihat data atau data yang salah.

Perilaku USERNAME() untuk tamu B2B di RLS Power BI

Fungsi USERNAME() DAX mengembalikan pengidentifikasi pengguna domain\username . Untuk pengguna tamu B2B, USERNAME() sering mengembalikan pengidentifikasi mirip UPN yang mirip dengan USERPRINCIPALNAME(), bergantung pada konfigurasi (misalnya, user@partner.com), bukan dalam format domain\username. Karena USERNAME() dan USERPRINCIPALNAME() sering mengembalikan nilai yang sama untuk tamu B2B, sebagian besar implementasi digunakan USERPRINCIPALNAME() untuk konsistensi.

Petunjuk / Saran

Jika RLS dinamis Anda yang ada menggunakan USERNAME(), verifikasi nilai apa yang dikembalikannya untuk pengguna tamu di lingkungan Anda sebelum berbagi konten secara eksternal. Anda dapat memeriksa dengan menambahkan visual kartu yang ditampilkan USERNAME() dalam laporan pengujian.

Pendekatan yang direkomendasikan: Simpan dan gunakan format pengidentifikasi yang sama secara konsisten dalam tabel pemetaan pengguna Anda sebagai nilai yang dikembalikan oleh USERPRINCIPALNAME(). Dalam kebanyakan kasus, menggunakan alamat email menyederhanakan manajemen:

[UserEmail] = USERPRINCIPALNAME()

UserEmail Di mana kolom berisi alamat email seperti user@partner.com untuk pengguna internal dan eksternal.

Catatan

Nilai yang dikembalikan oleh USERPRINCIPALNAME() adalah pengidentifikasi masuk (UPN) pengguna, belum tentu alamat email mereka. Untuk sebagian besar pengguna, ini sama, tetapi mereka dapat berbeda (misalnya, ketika email pengguna adalah alias). Saat membuat tabel pemetaan pengguna Anda, gunakan nilai yang dikembalikan oleh USERPRINCIPALNAME() daripada atribut mail dari Microsoft Entra ID.

Important

Jika Anda menggunakan RLS dinamis dengan USERPRINCIPALNAME(), selalu uji dengan pengguna tamu eksternal yang sebenarnya. Fitur Uji sebagai peran menggunakan identitas Anda sendiri dan tidak akan mengungkapkan masalah resolusi UPN pengguna eksternal.

Catatan

Perilaku resolusi UPN untuk tamu B2B dapat bervariasi tergantung pada konfigurasi Microsoft Entra ID Anda, seperti pengaturan akses lintas penyewa dan jenis pengguna tamu. Selalu validasi perilaku di lingkungan spesifik Anda.

Pemecahan masalah: Tamu B2B eksternal tidak melihat data dalam laporan Power BI

Jika pengguna tamu B2B melihat laporan kosong atau menerima pesan "tanpa data", ikuti langkah-langkah berikut:

  1. Verifikasi format UPN yang dikembalikan — Buat pengukuran pengujian menggunakan USERPRINCIPALNAME() dan tampilkan dalam visual kartu. Minta pengguna tamu melihat laporan untuk melihat nilai aktual yang dikembalikan.
  2. Periksa tabel pemetaan pengguna — Konfirmasikan tabel pemetaan berisi baris dengan nilai yang sama persis dengan apa yang USERPRINCIPALNAME() dikembalikan untuk tamu tersebut.
  3. Periksa pembedaan huruf besar/kecil — Perbandingan string DAX secara bawaan tidak membedakan huruf besar dan huruf kecil, tetapi pastikan sumber data Anda tidak menghasilkan nilai yang membedakan huruf besar dan huruf kecil.
  4. Tinjau pengaturan akses lintas penyewa — Jika organisasi Anda menggunakan kebijakan akses lintas penyewa, ini dapat memengaruhi format UPN mana yang disajikan ke Power BI.
  5. Uji dengan pengguna tamu aktual — Fitur Uji sebagai peran menggunakan identitas Anda sendiri. Selalu validasi dengan akun tamu eksternal nyata.
  6. Verifikasi penetapan peran — Jika pengguna tamu melihat lebih banyak data dari yang diharapkan, konfirmasikan bahwa mereka ditetapkan ke peran RLS. Pengguna yang tidak ditetapkan ke peran RLS apa pun biasanya tidak melihat data (hasil kosong), karena RLS diberlakukan tetapi tidak ada peran yang cocok yang diterapkan. Filter DAX mengevaluasi TRUE/FALSE untuk setiap baris. Hanya baris yang mengembalikan TRUE yang terlihat. Segala sesuatu yang lain benar-benar dihapus.

Untuk informasi selengkapnya tentang berbagi konten Power BI dengan pengguna eksternal, lihat konten Distribusikan Power BI kepada pengguna tamu eksternal dengan Microsoft Entra B2B.

Pertimbangan dan batasan

Anda dapat melihat batasan saat ini untuk keamanan tingkat baris pada model cloud di sini:

  • Jika sebelumnya Anda menentukan peran dan aturan dalam layanan Power BI, Anda harus membuatnya kembali di Power BI Desktop.
  • Anda hanya dapat menentukan RLS pada model semantik yang dibuat dengan Power BI Desktop. Jika Anda ingin mengaktifkan RLS untuk model semantik yang dibuat dengan Excel, Anda harus mengonversi file Anda menjadi file Power BI Desktop (PBIX) terlebih dahulu. Pelajari selengkapnya.
  • Prinsipal layanan tidak dapat ditambahkan ke dalam peran Keamanan Tingkat Baris (RLS). Dengan demikian, RLS tidak diterapkan untuk aplikasi yang menggunakan prinsipal layanan sebagai identitas efektif akhir.
  • Hanya koneksi Impor dan DirectQuery yang didukung. Koneksi langsung ke Analysis Services ditangani dalam model lokal.
  • Dengan mengaktifkan RLS, menggunakan fungsi USERELATIONSHIP() dalam kueri dan ukuran DAX dapat menyebabkan kesalahan yang tidak terduga. Untuk mengatasi masalah ini, desain ulang ekspresi DAX Anda untuk menghindari USERELATIONSHIP() dan gunakan hubungan tingkat model atau pola DAX lainnya sebagai gantinya.
  • Fitur Pengujian sebagai peran/Penglihatan sebagai peran tidak berfungsi untuk model DirectQuery dengan single sign-on (SSO) diaktifkan.
  • Fitur "Tes sebagai peran/laporan sebagai peran" hanya menampilkan laporan dari ruang kerja model semantik.
  • Fitur Uji sebagai peran atau Ditampilkan sebagai peran tidak berfungsi untuk laporan paginasi.
  • Identitas berbasis token hanya berfungsi untuk model DirectQuery pada kapasitas yang terhubung ke Azure SQL Database yang dikonfigurasi untuk mengizinkan autentikasi Microsoft Entra. Untuk informasi selengkapnya, lihat Menyematkan laporan dengan identitas berbasis token
  • Parameter 'IdentityBlob' adalah token akses OAuth 2.0 untuk Azure SQL dan hanya didukung untuk himpunan data dengan koneksi DirectQuery ke Azure SQL. Mekanismenya sendiri bersifat spesifik Azure-SQL: Blob is token akses Microsoft Entra yang dilingkup ke https://database.windows.net/.default. Tidak ada mekanisme lolos token yang setara untuk sumber data lain dalam penyematan data milik aplikasi. Untuk informasi selengkapnya, lihat referensi REST API untuk GenerateToken.

Pertimbangan dan batasan untuk RLS dinamis

Saat Anda menggunakan keamanan tingkat baris dinamis (RLS) dengan fungsi DAX seperti USERPRINCIPALNAME(), , USERNAME()atau CUSTOMDATA(), perhatikan pertimbangan berikut.

Skenario lintas penyewa B2B

Dalam skenario B2B, USERPRINCIPALNAME() mengembalikan identitas sesuai yang ditentukan oleh layanan Power BI, yang mungkin berbeda-beda bergantung pada konfigurasi tenant. Ini dapat muncul sebagai:

  • Alamat email pengguna eksternal (user@partner.com), atau
  • Nilai yang ditentukan tenant, seperti user_partner.com#EXT#@tenant.onmicrosoft.com

Format yang tepat tidak dijamin dan harus divalidasi di lingkungan Anda.

Jika tabel pemetaan pengguna Anda menyimpan identifier dalam format yang berbeda dibandingkan dengan format yang dikembalikan USERPRINCIPALNAME() untuk pengguna tamu, ekspresi filter RLS tidak akan sesuai, dan pengguna tamu tidak akan melihat data apa pun atau akan melihat data yang salah. Selalu verifikasi nilai pasti yang dikembalikan oleh USERPRINCIPALNAME() untuk pengguna eksternal di lingkungan Anda.

Petunjuk / Saran

Buat pengukuran pengujian menggunakan USERPRINCIPALNAME() dan tampilkan dalam visual kartu. Minta pengguna tamu eksternal melihat laporan untuk mengonfirmasi nilai yang dikembalikan cocok dengan tabel pemetaan pengguna Anda. Pengujian sederhana ini dapat mencegah berjam-jam debugging akibat nilai identitas yang tidak cocok.

Uji batasan peran dengan RLS dinamis

Fitur Uji sebagai peran di layanan Power BI menggunakan identitas Anda sendiri saat mengevaluasi ekspresi RLS dinamis. Ini berarti USERPRINCIPALNAME() mengembalikan UPN Anda , bukan dari pengguna yang Anda coba simulasikan. Anda tidak dapat menggunakan Test as role untuk melihat apa yang dilihat pengguna tamu B2B atau prinsipal layanan tertentu.

Test as role mensimulasikan keanggotaan peran, tetapi tidak sepenuhnya meniru konteks autentikasi pengguna lain, terutama untuk tamu B2B atau skenario tersemat.

Untuk memvalidasi RLS dinamis untuk pengguna eksternal, masuk sebagai pengguna tamu aktual dan lihat laporan secara langsung. Ini adalah satu-satunya cara untuk mengonfirmasi bahwa USERPRINCIPALNAME() mengembalikan nilai yang diharapkan dan bahwa filter RLS diterapkan dengan benar untuk pengguna tersebut.

Skenario yang disematkan dengan perwakilan layanan

Saat laporan diakses melalui aplikasi yang disematkan yang mengautentikasi dengan perwakilan layanan, USERPRINCIPALNAME() dan USERNAME() mengembalikan ID aplikasi perwakilan layanan atau string kosong—bukan identitas pengguna akhir.

Fungsi-fungsi ini tidak mengembalikan identitas pengguna akhir sehingga tidak dapat digunakan untuk pemfilteran per-pengguna dalam skenario penyematan service principal. Ini berarti filter RLS dinamis berdasarkan fungsi-fungsi ini tidak akan memfilter data per pengguna dalam skenario yang disematkan.

Untuk menerapkan RLS per pengguna dalam skenario yang disematkan, gunakan fitur effective identity Power BI REST API. Sertakan objek EffectiveIdentity dengan nama pengguna dan peran yang sesuai saat membuat token embed. Jika aturan RLS Anda menggunakan CUSTOMDATA(), teruskan string data kustom melalui EffectiveIdentity.CustomData.

Untuk informasi selengkapnya, lihat RLS untuk skenario Tersemat untuk ISV.

Important

Saat melakukan penyematan dengan service principal, selalu uji menggunakan token embed aktual yang menyertakan EffectiveIdentity untuk memastikan bahwa filter RLS diterapkan dengan benar. Fitur Uji sebagai peran di layanan Power BI tidak mensimulasikan alur autentikasi tersemat.

Perlu diingat bahwa jika laporan Power BI mereferensikan baris dengan RLS yang dikonfigurasi, maka pesan yang sama ditampilkan seperti untuk bidang yang dihapus atau tidak ada. Bagi pengguna ini, sepertinya laporan rusak.

FAQ

Pertanyaan: Bagaimana jika sebelumnya saya telah membuat peran dan aturan untuk himpunan data di layanan Power BI? Apakah mereka masih bekerja jika saya tidak melakukan apa-apa?
Jawaban: Tidak, visual tidak akan dirender dengan benar. Anda harus membuat ulang peran dan aturan dalam Power BI Desktop lalu menerbitkan ke layanan Power BI.

Pertanyaan: Bisakah saya membuat peran ini untuk sumber data Analysis Services?
Jawaban: Ya, jika Anda mengimpor data ke Power BI Desktop. Jika Anda menggunakan koneksi langsung, Anda tidak dapat mengonfigurasi RLS dalam layanan Power BI. Anda mendefinisikan RLS dalam model Analysis Services di lokasi.

Pertanyaan: Bisakah saya menggunakan RLS untuk membatasi kolom atau pengukuran yang dapat diakses oleh pengguna saya?
Jawaban: Tidak, jika pengguna memiliki akses ke baris data tertentu, mereka bisa melihat semua kolom data untuk baris tersebut. Untuk membatasi akses ke metadata kolom dan kolom, pertimbangkan untuk menggunakan keamanan tingkat objek.

Pertanyaan: Apakah RLS memungkinkan saya menyembunyikan data terperinci tetapi memberikan akses ke data yang dirangkum dalam visual?
Jawaban: Tidak, Anda mengamankan baris data individual, tetapi pengguna selalu dapat melihat detail atau data yang dirangkum.

Pertanyaan: Sumber data saya sudah memiliki peran keamanan yang ditentukan (misalnya peran SQL Server atau peran SAP BW). Apa hubungan antara peran ini dan RLS?
Jawaban: Jawabannya tergantung pada apakah Anda mengimpor data atau menggunakan DirectQuery. Jika Anda mengimpor data ke himpunan data Power BI, peran keamanan di sumber data Anda tidak digunakan. Dalam hal ini, Anda harus menentukan RLS untuk menerapkan aturan keamanan bagi pengguna yang tersambung di Power BI. Jika Anda menggunakan DirectQuery, peran keamanan di sumber data Anda akan digunakan. Saat pengguna membuka laporan, Power BI mengirim kueri ke sumber data yang mendasar, yang menerapkan aturan keamanan ke data berdasarkan kredensial pengguna.

Pertanyaan: Bisakah pengguna memiliki lebih dari satu peran?
Jawaban: Pengguna dapat termasuk dalam beberapa peran, dan perannya bersifat aditif. Misalnya, jika pengguna termasuk dalam peran "Penjualan" dan "Pemasaran", mereka dapat melihat data untuk kedua peran ini.

Konten terkait

Pertanyaan? Coba tanyakan kepada Komunitas Power BI Apakah ada saran? Sumbang ide untuk meningkatkan Power BI

  • Last updated on