Mengapa RLS Power BI Anda Berfungsi di Desktop tetapi Bocor di Fabric

By Mirko Peters · 2026-08-11

Selamat datang kembali di blog rekayasa data dan analitik! Jika Anda pernah membangun dashboard yang memukau, memverifikasi Row-Level Security Anda secara lokal di Power BI Desktop, mempublikasikannya ke cloud, lalu panik saat pengguna standar mengakses informasi yang seharusnya tidak boleh mereka lihat, Anda pasti tidak sendirian. Arsitektur keamanan di lingkungan analitik modern memang terkenal

Automatically translated with AI from the original post. Read the English original

Titelbild: Why Your Power BI RLS Works in Desktop But Leaks in Fabric

Dalam artikel ini, kita akan membahas secara mendalam mengapa RLS Power BI Anda mungkin bocor setelah deployment, bagaimana pemetaan identitas berbeda antara kedua lingkungan, dan bagaimana Anda dapat menerapkan pola keamanan yang tangguh dan native cloud. Mari kita bedah arsitektur di balik keamanan data perusahaan.

Konsep inti (model mental)

Sebelum menulis satu baris pun Data Analysis Expressions, atau DAX, Anda perlu memahami model mental keamanan yang benar. Terlalu banyak pengembang yang memperlakukan Row-Level Security sebagai fitur centang sederhana atau pengaturan administratif cepat di akhir proyek. Pada kenyataannya, keamanan adalah sistem yang saling terhubung.

Keamanan yang mengutamakan model: Relasi dan arah filter menentukan bagaimana RLS merambat. Jika model data Anda memiliki relasi yang rusak atau jalur many-to-many yang tidak terduga, filter keamanan tidak akan mengalir dengan benar ke tabel fakta Anda.
Desain peran: Peran yang lebih sedikit dan dirancang dengan tujuan jelas lebih baik daripada peran yang banyak dan saling tumpang tindih. Membuat seratus peran statis untuk setiap pengguna akan dengan cepat menjadi mimpi buruk administratif.
Konteks dinamis: Keamanan harus merespons siapa yang melihat laporan dan apa yang berhubungan dengan mereka dalam organisasi yang lebih luas.
Realitas cloud: Resolusi identitas dan pengaturan penyewa di Fabric dapat mengubah perilaku secara signifikan dibandingkan dengan mesin lokal Anda. Memahami cara cloud memetakan identitas pengguna adalah hal yang wajib.

Merancang filter yang tahan uji (pola DAX)

Menulis ekspresi DAX yang aman untuk peran Anda adalah landasan isolasi data yang efektif. Bergantung pada struktur organisasi dan skala organisasi Anda, kemungkinan besar Anda akan memilih antara pola filter statis dan dinamis.

RLS statis (sederhana, audiens tetap)

Contoh pada DimRegion:
DimRegion[Region] = "US"

RLS dinamis melalui tabel jembatan (direkomendasikan)

Tabel: Users (UPN, UserKey), UserRegion (UserKey, RegionKey), DimRegion (RegionKey, Region)
Filter peran pada Users:
Users[UPN] = USERPRINCIPALNAME()
Secara opsional, batasi DimRegion menggunakan relasi dari Users > UserRegion > DimRegion.

Hindari

Keamanan berbasis kolom kalkulasi, yang dievaluasi saat penyegaran data, bukan secara dinamis per konteks pengguna.
USERNAME() di Fabric (selalu gunakan USERPRINCIPALNAME(); pastikan untuk menguji secara menyeluruh format email dan sufiks UPN).
Menuliskan email atau domain individu secara langsung di dalam ekspresi filter Anda.

Pola dinamis yang membantu

Model multi-penyewa: petakan TenantId dari tabel Users pusat Anda langsung ke tabel fakta dan dimensi.
Hierarki: simpan tautan manajer-bawahan, buat tabel akses yang terwujud, lalu filter berdasarkan seluruh turunan struktural bagi pengguna yang sedang melihat.

Desain peran & relasi

Bentuk model data Anda menentukan batas keamanan Anda. Gunakan filter satu arah bila memungkinkan untuk menghindari jalur many-to-many yang ambigu yang secara tidak sengaja melewati batasan keamanan. Buat dimensi keamanan khusus, seperti tabel jembatan User-to-Access, daripada menyisipkan logika bisnis yang kompleks langsung ke tabel fakta Anda. Selalu utamakan beberapa peran yang dapat digunakan kembali dengan filter dinamis daripada puluhan peran statis.

Penugasan tanpa kejutan (pengguna & grup)

Mengelola penugasan secara efisien sangat penting untuk kesehatan operasional jangka panjang. Selalu petakan peran Anda ke grup Azure AD, bukan ke akun pengguna individual, agar sistem tetap dapat diskalakan dengan baik ketika karyawan berpindah tim. Cegah keanggotaan yang usang dengan menjadwalkan tinjauan akses triwulanan bersama pemilik grup. Waspadai keanggotaan grup yang tumpang tindih, karena pengguna yang tergabung dalam beberapa grup keamanan dapat secara tidak sengaja memperluas akses data mereka.

Desktop vs Fabric: apa yang berubah setelah publikasi

Di sinilah sebagian besar kebocoran keamanan terjadi. Di Power BI Desktop, Anda bekerja dalam sandbox lokal yang terkendali. Setelah dipublikasikan ke Microsoft Fabric, cloud mengambil alih pengelolaan identitas. USERPRINCIPALNAME() mengembalikan alamat email cloud di Fabric, sedangkan pratinjau di Desktop dapat berperilaku berbeda tergantung pada kredensial lokal. Selain itu, pemilik dataset, kredensial penyegaran, pengaturan ruang kerja, dan latensi sinkronisasi grup di Azure AD dapat mengubah apa yang pada akhirnya boleh dilihat oleh pengguna.

Pengujian yang benar-benar mendeteksi kebocoran

Jangan pernah hanya mengandalkan fitur "Lihat sebagai" di Power BI Desktop untuk menyetujui keamanan produksi. Meskipun berguna untuk pemeriksaan cepat, Anda harus menguji di Fabric. Validasi dengan grup keamanan dan akun pengguna yang sesungguhnya di ruang kerja non-produksi. Uji setiap peran pada halaman laporan inti dan visual yang sensitif. Pertimbangkan untuk membuat skrip pemeriksaan acak melalui endpoint XMLA atau alat otomatisasi guna mengekspor kumpulan hasil kecil untuk akun uji yang sudah diketahui.

Tata kelola & operasi

Menjaga keamanan dari waktu ke waktu membutuhkan tata kelola yang ketat. Catat semua peran Anda, dokumentasikan filter DAX-nya, daftar tabel yang terdampak, dan catat audiens yang dituju. Terapkan kontrol perubahan melalui pull request yang mewajibkan bukti pengujian RLS sebelum pembaruan model digabungkan. Tentukan kontrak data yang jelas yang menetapkan dimensi dan fakta mana yang harus terlibat dalam RLS. Jalankan resertifikasi keanggotaan grup setiap triwulan dan pantau laporan berisiko tinggi Anda untuk mendeteksi anomali.

Pola kegagalan umum (dan perbaikannya)

Jika Anda menghadapi masalah, periksa terhadap pola kegagalan umum berikut:

Berfungsi di Desktop, bocor di Fabric: Disebabkan oleh penggunaan USERNAME() atau format identitas yang tidak cocok. Perbaikan: Gunakan USERPRINCIPALNAME() secara konsisten dan sesuaikan nilai Users[UPN] Anda.
Pengguna melihat terlalu banyak: Disebabkan oleh jalur many-to-many yang melewati keamanan. Perbaikan: Tambahkan dimensi keamanan dan perketat relasi.
Akses tim lama masih bertahan: Disebabkan oleh keanggotaan grup Azure AD yang usang. Perbaikan: Otomatisasi alur resertifikasi dan proses penghapusan.
Kolom kalkulasi digunakan untuk identitas: Tidak memberikan efek per pengguna. Perbaikan: Pindahkan logika ke DAX filter peran di atas tabel model.

Daftar periksa mulai cepat (minggu ini)

Tambahkan tabel Users yang dikunci dengan USERPRINCIPALNAME() dan relasikan ke tabel akses Anda.
Ubah filter yang di-hardcode menjadi filter dinamis berbasis tabel jika sesuai.
Ganti logika USERNAME() apa pun dengan USERPRINCIPALNAME() dan uji ulang di Fabric.
Petakan peran ke grup AAD dan jadwalkan tinjauan akses bersama pemilik grup.
Publikasikan ke ruang kerja uji, validasi dengan pengguna sungguhan, dan perbaiki setiap celah identitas.
Dokumentasikan peran, DAX, dan tabel Anda di dalam README model Anda.

Aset SEO yang disarankan

Slug URL: power-bi-row-level-security-architecture
Meta title: Power BI Row-Level Security: Arsitektur, Pola DAX, dan Tata Kelola Siap Cloud
Meta description: Lebih dari sekadar kotak centang RLS. Pelajari pola DAX dinamis, desain peran, pemetaan Azure AD, dan pengujian khusus Fabric untuk menjaga data sensitif tetap benar-benar aman.
Kata kunci: Power BI, Row-Level Security, RLS, USERPRINCIPALNAME, grup Azure AD, Fabric, RLS dinamis, tata kelola data

Kesimpulan

Row-level security bukanlah fitur yang cukup Anda konfigurasi sekali lalu dilupakan. Ini adalah sistem yang hidup dan terus berkembang, yang terdiri atas model data, relasi, formula DAX, pemetaan identitas, dan pengaturan tata kelola cloud. Dengan beralih dari peran statis yang rapuh, menerapkan tabel jembatan dinamis yang andal, dan menguji secara ketat di dalam Microsoft Fabric, Anda dapat memastikan data Anda tetap aman seiring pertumbuhan dan perubahan organisasi Anda.

Untuk mendalami topik ini lebih jauh dan mendengar strategi implementasi praktisnya, pastikan Anda menonton episode podcast terkait kami: Implement Power BI Row-Level Security in Microsoft Fabric. Jangan hanya mengunci data Anda—rancang arsitektur keamanan yang tangguh dan mampu beradaptasi seiring berkembangnya organisasi Anda!