Panduan keamanan tingkat baris (RLS) dalam Power BI Desktop

Artikel ini menargetkan Anda sebagai pemodel data yang bekerja dengan Power BI Desktop. Ini menjelaskan praktik desain yang baik untuk memberlakukan keamanan tingkat baris (RLS) dalam model data Anda.

Penting untuk memahami baris tabel filter RLS. Mereka tidak dapat dikonfigurasi untuk membatasi akses ke objek model, termasuk tabel, kolom, atau pengukuran.

Catatan

Artikel ini tidak menjelaskan RLS atau cara menyiapkannya. Untuk informasi selengkapnya, lihat Membatasi akses data dengan keamanan tingkat baris (RLS) untuk Power BI Desktop.

Selain itu, ini tidak mencakup pemberlakuan RLS dalam koneksi langsung ke model yang dihosting eksternal dengan Azure Analysis Services atau SQL Server Analysis Services. Dalam kasus ini, RLS diberlakukan oleh Analysis Services. Saat Power BI terhubung menggunakan akses menyeluruh (SSO), Analysis Services akan memberlakukan RLS (kecuali akun memiliki hak istimewa admin).

Buat peran

Dimungkinkan untuk membuat beberapa peran. Saat Anda mempertimbangkan kebutuhan izin untuk satu pengguna laporan, upayakan untuk membuat satu peran yang memberikan semua izin tersebut, alih-alih desain di mana pengguna laporan akan menjadi anggota dari beberapa peran. Ini karena pengguna laporan dapat memetakan ke beberapa peran, baik secara langsung dengan menggunakan akun pengguna mereka atau secara tidak langsung oleh keanggotaan grup keamanan. Beberapa pemetaan peran dapat mengakibatkan hasil yang tidak terduga.

Saat pengguna laporan ditetapkan ke beberapa peran, filter RLS menjadi aditif. Ini berarti pengguna laporan dapat melihat baris tabel yang mewakili persatuan filter tersebut. Terlebih lagi, dalam beberapa skenario tidak dimungkinkan untuk menjamin bahwa pengguna laporan tidak melihat baris dalam tabel. Jadi, tidak seperti izin yang diterapkan ke SQL Server objek database (dan model izin lainnya), prinsip "setelah ditolak selalu ditolak" tidak berlaku.

Pertimbangkan model dengan dua peran: Peran pertama, bernama Pekerja, membatasi akses ke semua baris tabel Payroll dengan menggunakan ekspresi aturan berikut:

FALSE()

Catatan

Aturan tidak akan mengembalikan baris tabel saat ekspresinya dievaluasi ke FALSE.

Namun, peran kedua, bernama Manajer, memungkinkan akses ke semua baris tabel Payroll dengan menggunakan ekspresi aturan berikut:

TRUE()

Berhati-hatilah: Jika pengguna melaporkan peta ke kedua peran, mereka akan melihat semua baris tabel Payroll.

Optimalkan RLS

RLS bekerja dengan menerapkan filter secara otomatis ke setiap kueri DAX, dan filter ini mungkin berdampak negatif pada performa kueri. Jadi, RLS yang efisien turun ke desain model yang baik. Penting untuk mengikuti panduan desain model, seperti yang dibahas dalam artikel berikut:

• Memahami skema bintang dan pentingnya Power BI
• Semua artikel panduan hubungan yang ditemukan dalam dokumentasi panduan Power BI

Secara umum, sering kali lebih efisien untuk memberlakukan filter RLS pada tabel jenis dimensi, dan bukan tabel jenis fakta. Dan, andalkan hubungan yang dirancang dengan baik untuk memastikan filter RLS menyebar ke tabel model lain. Filter RLS hanya disebarluaskan melalui hubungan aktif. Jadi, hindari menggunakan fungsi LOOKUPVALUE DAX ketika hubungan model dapat mencapai hasil yang sama.

Setiap kali filter RLS diberlakukan pada tabel DirectQuery dan ada hubungan dengan tabel DirectQuery lainnya, pastikan untuk mengoptimalkan database sumber. Ini dapat melibatkan merancang indeks yang sesuai atau menggunakan kolom komputasi yang bertahan. Untuk informasi selengkapnya, lihat Panduan model DirectQuery di Power BI Desktop.

Mengukur dampak RLS

Dimungkinkan untuk mengukur dampak performa filter RLS dalam Power BI Desktop dengan menggunakan Penganalisis Kinerja. Pertama, tentukan durasi kueri visual laporan saat RLS tidak diberlakukan. Lalu, gunakan perintah Tampilkan Sebagai pada tab pita Pemodelan untuk memberlakukan RLS dan menentukan dan membandingkan durasi kueri.

Mengonfigurasi pemetaan peran

Setelah diterbitkan ke Power BI, Anda harus memetakan anggota ke peran model semantik (sebelumnya dikenal sebagai himpunan data). Hanya pemilik model semantik atau admin ruang kerja yang dapat menambahkan anggota ke peran. Untuk informasi selengkapnya, lihat Keamanan tingkat baris (RLS) dengan Power BI (Mengelola keamanan pada model Anda).

Anggota dapat berupa akun pengguna, grup keamanan, grup distribusi, atau grup yang diaktifkan email. Jika memungkinkan, kami sarankan Anda memetakan kelompok keamanan ke peran model semantik. Ini melibatkan pengelolaan keanggotaan grup keamanan di ID Microsoft Entra (sebelumnya dikenal sebagai Azure Active Directory). Mungkin, ini mendelegasikan tugas kepada administrator jaringan Anda.

Memvalidasi peran

Uji setiap peran untuk memastikan model memfilter model dengan benar. Ini mudah dilakukan dengan menggunakan perintah Tampilkan Sebagai pada tab pita Pemodelan.

Ketika model memiliki aturan dinamis menggunakan fungsi USERNAME DAX, pastikan untuk menguji nilai yang diharapkan dan tidak terduga. Saat menyematkan konten Power BI—khususnya menggunakan sematan untuk skenario pelanggan Anda—logika aplikasi dapat meneruskan nilai apa pun sebagai nama pengguna identitas yang efektif. Jika memungkinkan, pastikan nilai yang tidak disengaja atau berbahaya menghasilkan filter yang tidak mengembalikan baris.

Pertimbangkan contoh menggunakan Power BI disematkan, di mana aplikasi meneruskan peran pekerjaan pengguna sebagai nama pengguna yang efektif: Perannya adalah "Manajer" atau "Pekerja". Manajer dapat melihat semua baris, tetapi pekerja hanya dapat melihat baris di mana nilai kolom Jenis adalah "Internal".

Ekspresi aturan berikut didefinisikan:

IF(
    USERNAME() = "Worker",
    [Type] = "Internal",
    TRUE()
)

Masalah dengan ekspresi aturan ini adalah bahwa semua nilai, kecuali "Pekerja", mengembalikan semua baris tabel. Jadi, nilai yang tidak disengaja, seperti "Pekerja", secara tidak sengaja mengembalikan semua baris tabel. Oleh karena itu, lebih aman untuk menulis ekspresi yang menguji untuk setiap nilai yang diharapkan. Dalam ekspresi aturan yang ditingkatkan berikut, nilai yang tidak terduga menghasilkan tabel yang tidak mengembalikan baris.

IF(
    USERNAME() = "Worker",
    [Type] = "Internal",
    IF(
        USERNAME() = "Manager",
        TRUE(),
        FALSE()
    )
)

Merancang RLS parsial

Terkadang, perhitungan memerlukan nilai yang tidak dibatasi oleh filter RLS. Misalnya, laporan mungkin perlu menampilkan rasio pendapatan yang diperoleh untuk wilayah penjualan pengguna laporan atas semua pendapatan yang diperoleh.

Meskipun ekspresi DAX tidak dapat mengambil alih RLS—bahkan tidak dapat menentukan bahwa RLS diberlakukan—Anda dapat menggunakan tabel model ringkasan. Tabel model ringkasan dikueri untuk mengambil pendapatan untuk "semua wilayah" dan tidak dibatasi oleh filter RLS apa pun.

Mari kita lihat bagaimana Anda dapat menerapkan persyaratan desain ini. Pertama, pertimbangkan desain model berikut:

Model ini terdiri atas empat tabel:

• Tabel Tenaga Penjual menyimpan satu baris per tenaga penjual. Ini termasuk kolom EmailAddress, yang menyimpan alamat email untuk setiap tenaga penjual. Tabel ini tersembunyi.
• Tabel Penjualan menyimpan satu baris per pesanan. Ini termasuk ukuran Pendapatan % Semua Wilayah, yang dirancang untuk mengembalikan rasio pendapatan yang diperoleh oleh wilayah pengguna laporan atas pendapatan yang diperoleh oleh semua wilayah.
• Tabel Tanggal menyimpan satu baris per tanggal dan memungkinkan pemfilteran dan pengelompokan tahun dan bulan.
• SalesRevenueSummary adalah tabel terhitung. Tabel ini menyimpan total pendapatan untuk setiap tanggal pesanan. Tabel ini tersembunyi.

Ekspresi berikut menentukan tabel terhitung SalesRevenueSummary:

SalesRevenueSummary =
SUMMARIZECOLUMNS(
    Sales[OrderDate],
    "RevenueAllRegion", SUM(Sales[Revenue])
)

Catatan

Tabel agregasi dapat mencapai persyaratan desain yang sama.

Aturan RLS berikut diterapkan ke tabel Tenaga Penjual:

[EmailAddress] = USERNAME()

Masing-masing dari tiga hubungan model dijelaskan dalam tabel berikut:

Hubungan	Deskripsi
	Ada hubungan banyak ke banyak antara tabel Tenaga Penjual dan Penjualan. Aturan RLS memfilter kolom EmailAddress dari tabel Tenaga Penjual tersembunyi dengan menggunakan fungsi USERNAME DAX. Nilai kolom Wilayah (untuk pengguna laporan) disebarluaskan ke tabel Penjualan.
	Ada hubungan satu-ke-banyak antara tabel Tanggal dan Penjualan .
	Ada hubungan satu-ke-banyak antara tabel Date dan SalesRevenueSummary .

Ekspresi berikut mendefinisikan ukuran Pendapatan % Semua Wilayah:

Revenue % All Region =
DIVIDE(
    SUM(Sales[Revenue]),
    SUM(SalesRevenueSummary[RevenueAllRegion])
)

Catatan

Berhati-hatilah untuk menghindari pengungkapan fakta sensitif. Jika hanya ada dua wilayah dalam contoh ini, maka pengguna laporan dapat menghitung pendapatan untuk wilayah lain.

Kapan harus menghindari penggunaan RLS

Terkadang masuk akal untuk menghindari penggunaan RLS. Jika Anda hanya memiliki beberapa aturan RLS sederhana yang menerapkan filter statis, pertimbangkan untuk menerbitkan beberapa model semantik sebagai gantinya. Tidak ada model semantik yang menentukan peran karena setiap model semantik berisi data untuk audiens pengguna laporan tertentu, yang memiliki izin data yang sama. Kemudian, buat satu ruang kerja per audiens dan tetapkan izin akses ke ruang kerja atau aplikasi.

Misalnya, perusahaan yang hanya memiliki dua wilayah penjualan memutuskan untuk menerbitkan model semantik untuk setiap wilayah penjualan ke ruang kerja yang berbeda. Model semantik tidak memberlakukan RLS. Namun, mereka menggunakan parameter kueri untuk memfilter data sumber. Dengan cara ini, model yang sama diterbitkan ke setiap ruang kerja—model tersebut hanya memiliki nilai parameter model semantik yang berbeda. Tenaga penjualan diberi akses hanya ke salah satu ruang kerja (atau aplikasi yang diterbitkan).

Ada beberapa keuntungan yang terkait dengan menghindari RLS:

• Performa kueri yang ditingkatkan: Ini dapat mengakibatkan peningkatan performa karena lebih sedikit filter.
• Model yang lebih kecil: Meskipun menghasilkan lebih banyak model, ukurannya lebih kecil. Model yang lebih kecil dapat meningkatkan responsivitas kueri dan refresh data, terutama jika kapasitas hosting mengalami tekanan pada sumber daya. Selain itu, lebih mudah untuk menjaga ukuran model di bawah batas ukuran yang diberlakukan oleh kapasitas Anda. Terakhir, lebih mudah untuk menyeimbangkan beban kerja di berbagai kapasitas, karena Anda dapat membuat ruang kerja—atau memindahkan ruang kerja ke—kapasitas yang berbeda.
• Fitur tambahan: Power BI fitur yang tidak berfungsi dengan RLS, seperti Terbitkan ke web, dapat digunakan.

Namun, ada kerugian yang terkait dengan menghindari RLS:

• Beberapa ruang kerja: Satu ruang kerja diperlukan untuk setiap audiens pengguna laporan. Jika aplikasi diterbitkan, itu juga berarti ada satu aplikasi per audiens pengguna laporan.
• Duplikasi konten: Laporan dan dasbor harus dibuat di setiap ruang kerja. Ini membutuhkan lebih banyak upaya dan waktu untuk mengatur dan memelihara.
• Pengguna hak istimewa tinggi: Pengguna hak istimewa tinggi, yang termasuk dalam beberapa audiens pengguna laporan, tidak dapat melihat tampilan data yang dikonsolidasikan. Mereka harus membuka beberapa laporan (dari ruang kerja atau aplikasi yang berbeda).

Memecahkan masalah RLS

Jika RLS menghasilkan hasil yang tidak terduga, periksa masalah berikut:

• Hubungan yang salah ada di antara tabel model, dalam hal pemetaan kolom dan arah filter. Perlu diingat bahwa filter RLS hanya disebarluaskan melalui hubungan aktif.
• Properti Terapkan filter keamanan di kedua arah hubungan tidak diatur dengan benar. Untuk informasi lebih lanjut, lihat Panduan hubungan dua arah.
• Tabel tidak berisi data.
• Nilai yang salah dimuat ke dalam tabel.
• Pengguna dipetakan ke beberapa peran.
• Model ini menyertakan tabel agregasi, dan aturan RLS tidak secara konsisten memfilter agregasi dan detail. Untuk informasi selengkapnya, lihat Menggunakan agregasi di Power BI Desktop (RLS untuk agregasi).

Saat pengguna tertentu tidak dapat melihat data apa pun, itu bisa jadi karena UPN mereka tidak disimpan atau salah dimasukkan. Ini dapat terjadi tiba-tiba karena akun pengguna mereka telah berubah sebagai akibat dari perubahan nama.

Tip

Untuk tujuan pengujian, tambahkan ukuran yang mengembalikan fungsi USERNAME DAX. Anda mungkin menamainya seperti "Siapa saya". Kemudian, tambahkan pengukuran ke visual kartu dalam laporan dan terbitkan ke Power BI.

Pembuat dan konsumen hanya dengan izin Baca pada model semantik hanya akan dapat melihat data yang diizinkan untuk mereka lihat (berdasarkan pemetaan peran RLS mereka).

Saat pengguna melihat laporan di ruang kerja atau aplikasi, RLS mungkin atau mungkin tidak diberlakukan tergantung pada izin model semantik mereka. Untuk alasan ini, sangat penting bahwa konsumen konten dan pembuat hanya memiliki izin Baca pada model semantik yang mendasar ketika RLS harus diberlakukan. Untuk detail tentang aturan izin yang menentukan apakah RLS diberlakukan, lihat artikel Melaporkan perencanaan keamanan konsumen.

Konten terkait

Untuk informasi selengkapnya tentang dokumen resmi ini, lihat sumber daya berikut:

• Keamanan tingkat baris (RLS) dengan Power BI
• Membatasi akses data dengan keamanan tingkat baris (RLS) untuk Power BI Desktop
• Hubungan model di Power BI Desktop
• Perencanaan implementasi Power BI: Melaporkan perencanaan keamanan konsumen
• Pertanyaan? Coba tanyakan kepada Komunitas Power BI
• Ada saran? Sumbang ide untuk meningkatkan Power BI