M365Con 2027 – konferensi online gratis · 11–22 Jan 2027 · 120 sessions→ m365con.net

Blog · Mirko Peters

Mengimplementasikan Dynamic Row-Level Security di Power BI dan Microsoft Fabric: Arsitektur, Pola DAX, dan Tata Kelola Tingkat Enterprise

By · · Updated

Implementasikan dynamic row-level security di Power BI dan Microsoft Fabric untuk mengontrol akses data pengguna, memastikan kepatuhan, dan beradaptasi dengan perubahan organisasi.

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

▶ BLOGImplementing DynamicRow-Level Security in…M365.FM
Titelbild: Implementing Dynamic Row-Level Security in Power BI and Microsoft Fabric: Architecture, DAX Patterns, and Enterprise-Grade Governance

Anda sebaiknya memandang Dynamic Row-Level Security sebagai sebuah sistem yang dapat berubah. Sistem ini tumbuh dan berubah seiring dengan organisasi Anda. Desain model data, ekspresi DAX, identitas pengguna, dan tata kelola turut menentukan cara keamanan bekerja di Power BI dan Microsoft Fabric. Jika diatur dengan benar, Anda dapat menentukan siapa yang boleh melihat data tertentu.

Area Utama

Dampak pada RLS

Keamanan Dinamis

Memfilter data per pengguna, menggunakan DAX di dalam model

Tata Kelola

Memastikan akses mengikuti aturan dan tetap aman

Desain Model

Memungkinkan Anda mengontrol siapa yang melihat data sensitif

Poin Penting

Memikirkan Ulang Sistem Row-Level Security

Keamanan sebagai Sistem Berbasis Model

Row-level security adalah sistem yang menghubungkan berbagai bagian platform analitik Anda. Saat Anda membuat model data, Anda sebenarnya mulai membangun keamanan data. Cara Anda menyiapkan tabel, menghubungkannya, dan membuat peran memengaruhi cara orang melihat data. Jika perusahaan Anda berkembang atau tim baru bergabung, Anda perlu memperbarui aturan keamanan. Row-level security bukan sesuatu yang cukup diatur sekali lalu dilupakan. Aturan ini berubah seiring perubahan bisnis dan kebutuhan baru.

Tips: Periksa model data Anda secara berkala. Model yang baik memudahkan pengelolaan keamanan dan membantu Anda menghindari kesalahan.

Model Anda sebaiknya memiliki relasi yang jelas dan tabel keamanan khusus. Dengan begitu, Anda dapat mengontrol siapa yang melihat data tertentu sekaligus menjaga data privat tetap aman. Dynamic row-level security dapat mencocokkan apa yang dilihat pengguna dengan grup atau jabatan mereka di Fabric. Dengan cara ini, Anda dapat mengubah izin dengan cepat ketika perusahaan Anda berubah.

Static vs. Dynamic Row-Level Security

Ada dua cara utama untuk mengatur keamanan data: static dan dynamic row-level security. Static security menggunakan aturan tetap. Anda membuat peran dan filter untuk setiap grup. Pendekatan ini cocok untuk tim kecil atau ketika akses tidak sering berubah. Dynamic row-level security menggunakan identitas pengguna yang sedang login dan tabel pemetaan. Sistem ini memeriksa pengguna dan langsung mengubah data yang mereka lihat. Pendekatan ini lebih baik untuk perusahaan besar dengan banyak pengguna dan aturan yang sering berubah.

Berikut tabel yang menunjukkan perbedaannya:

Fitur

RLS (Static)

DLS (Dynamic)

Fleksibilitas

Rendah

Tinggi

Pengaturan

Peran manual

Berbasis aturan dengan pemetaan pengguna

Kasus Penggunaan Terbaik

Sedikit pengguna / akses tetap

Banyak pengguna / akses yang dipersonalisasi

Dynamic row-level security memberi Anda lebih banyak cara untuk mengontrol akses. Fitur ini menggunakan hal seperti USERPRINCIPALNAME() dan tabel pemetaan untuk mencocokkan pengguna dengan data yang tepat. Static security memang mudah, tetapi kurang efektif jika perusahaan Anda berkembang atau sering berubah.

Untuk menjaga keamanan data, pilih pendekatan yang paling sesuai dengan kebutuhan Anda. Perencanaan yang matang dan model yang kuat membantu Anda melindungi data privat dan menjaga keamanan analitik Anda.

Pola Dynamic Row-Level Security di Fabric

Fungsi DAX: USERPRINCIPALNAME() vs. USERNAME()

Penting untuk memahami cara kerja identitas di Fabric. Ada dua fungsi utama yang digunakan untuk mengatur row-level security, yaitu USERPRINCIPALNAME() dan USERNAME(). Keduanya memeriksa siapa yang sedang membuka laporan. USERPRINCIPALNAME() mengembalikan email pengguna dari cloud. USERNAME() sering kali mengembalikan nama akun lokal, terutama di Power BI Desktop. Jika Anda menggunakan USERNAME() di cloud, fungsi ini mungkin tidak bekerja dengan benar. Kondisi ini dapat membuat data Anda kurang aman.

Tip: Gunakan selalu USERPRINCIPALNAME() untuk keamanan baris dinamis (dynamic row-level security) di Fabric. Fungsi ini mencocokkan email cloud pengguna dan menjaga data Anda tetap aman.

Fungsi

Mengembalikan

Kasus Penggunaan Terbaik

USERPRINCIPALNAME()

Alamat email cloud

Fabric, Power BI cloud

USERNAME()

Nama akun lokal

Hanya untuk pengujian Desktop

Jika Anda menggunakan fungsi yang salah, pengguna bisa melihat data yang seharusnya tidak boleh mereka lihat. Anda perlu menguji keamanan di cloud, bukan hanya di Desktop.

Pola DAX Aman dan Anti-Pola

Anda ingin data Anda tetap aman. Anda memerlukan pola DAX yang kuat untuk keamanan baris dinamis. Cara terbaik adalah menggunakan tabel pemetaan (mapping table) dan aturan dinamis. Cara ini memungkinkan Anda mengontrol siapa yang dapat melihat apa.

Pola DAX yang baik menggunakan lookup untuk mencocokkan pengguna dengan grupnya. Cara ini bekerja dengan baik untuk perusahaan dengan banyak grup. Berikut contoh yang baik:

Organizations[Id] = LOOKUPVALUE(
    AspNetUsers[OrganizationId],
    AspNetUsers[Email],
    USERPRINCIPALNAME()
)

Pola ini memeriksa email pengguna dan mencari grupnya. Anda dapat menggunakannya untuk menampilkan hanya data yang sesuai. Cara ini lebih baik daripada sekadar mencocokkan email. Cara ini tetap efektif seiring pertumbuhan perusahaan dan menjaga data Anda tetap aman.

Catatan: Jangan menulis email secara hardcode atau menggunakan kolom kalkulasi untuk kontrol akses. Cara ini bisa rusak jika pengguna berubah atau perusahaan Anda makin besar.

Beberapa pola buruk dapat menyebabkan kebocoran data:

Anda sebaiknya selalu menggunakan aturan dinamis dan tabel pemetaan. Cara ini menjaga model data Anda tetap sederhana dan data Anda tetap aman.

Hierarki dan Fungsi PATH()

Terkadang Anda memerlukan keamanan untuk manajer, tim, atau departemen. Hierarki membantu Anda melakukannya. Fungsi PATH() di DAX memungkinkan Anda membangun hubungan induk-anak. Anda dapat menggunakannya untuk mengontrol siapa yang melihat apa di setiap level.

Misalnya, Anda dapat membuat tabel dengan ID karyawan dan ID manajer. PATH() membangun rantai dari setiap pekerja ke atasannya. Anda kemudian dapat menggunakan DAX untuk memfilter data untuk setiap level.

PATH(Employee[EmployeeID], Employee[ManagerID])

Fungsi ini membantu Anda menyiapkan keamanan baris dinamis untuk perusahaan besar. Anda dapat membiarkan manajer melihat data timnya. Anda juga dapat mencegah pekerja biasa melihat terlalu banyak.

Tip: Gunakan PATH() untuk keamanan dengan hierarki. Cara ini membuat model data Anda fleksibel dan menjaga data Anda tetap aman.

Anda dapat menggunakan filter baris, topeng kolom, dan fungsi hierarki secara bersamaan. Cara ini membantu melindungi data pribadi dan mengendalikan akses seiring pertumbuhan perusahaan Anda.

Arsitektur Peran dan Relasi

Desain Tabel Keamanan

Anda perlu membuat tabel keamanan untuk keamanan baris dinamis. Tabel ini menunjukkan pengguna mana yang dapat melihat data apa. Gunakan kolom untuk email pengguna, grup, dan tingkat akses. Pengaturan ini membantu Anda menjaga keamanan data seiring pertumbuhan perusahaan.
Saat membuat peran, pisahkan peran yang ketat dan peran yang terbuka. Jika satu peran memungkinkan seseorang melihat semuanya, peran lain dengan keamanan tingkat baris mungkin tidak berfungsi dengan benar. Anda harus mencegah peran saling bertentangan agar data tetap aman.

Relasi Model Data

Cara Anda membangun model data memengaruhi cara Anda mengontrol akses. Gunakan relasi satu arah antartabel. Cara ini membuat model Anda sederhana dan membantu menghindari kesalahan.
Lebih baik menggunakan tabel keamanan khusus daripada menempatkan izin di tabel fakta. Anda dapat menghubungkan tabel keamanan dengan tabel lain seperti departemen atau wilayah. Dengan cara ini, Anda dapat memfilter data untuk setiap pengguna atau grup.

Tip: Gunakan tabel jembatan (bridge table) untuk menghubungkan pengguna dengan data. Cara ini membantu keamanan baris dinamis berfungsi dan menjaga data Anda tetap aman.

Peran Granularitas: Peran Kecil vs. Peran Besar

Anda perlu memutuskan seberapa detail peran Anda. Peran yang kecil memberi Anda kendali lebih besar. Anda bisa memberikan akses berdasarkan pekerjaan atau grup. Peran yang besar mencakup lebih banyak orang, tetapi bisa berisiko jika ada perubahan.
Periksa siapa yang memiliki setiap peran secara berkala. Ini menjaga data Anda tetap aman dan memungkinkan Anda melakukan perubahan saat diperlukan.
Pilih peran yang kecil untuk kendali lebih baik dan pembaruan yang mudah. Peran yang besar mungkin cocok untuk grup sederhana, tetapi bisa menimbulkan masalah di perusahaan besar.

Penetapan Pengguna dan Grup di Fabric

Grup Azure AD vs. Individu

Anda memberikan akses di Fabric dengan memasukkan pengguna ke dalam grup Azure AD. Dengan cara ini, Anda dapat mengontrol data untuk banyak orang sekaligus. Menggunakan grup lebih aman daripada menambahkan setiap orang secara terpisah. Grup membantu Anda mengelola sistem dengan lebih sedikit pekerjaan. Saat tim Anda berubah, Anda dapat memperbarui grup dengan cepat. Menautkan grup ke peran memudahkan pemodelan data. Aturan row-level security Anda tetap jelas dan sederhana.

Tip: Gunakan grup Azure AD untuk kontrol akses. Ini membantu Anda membuat lebih sedikit kesalahan dan menghemat waktu.

Grup yang Tumpang Tindih dan Akses Bayangan

Anda perlu waspada terhadap grup yang tumpang tindih. Terkadang, seorang pengguna berada di lebih dari satu grup. Hal ini dapat membuat mereka melihat data yang seharusnya tidak boleh mereka lihat. Akses bayangan terjadi ketika kesalahan ini memungkinkan pengguna melihat data tambahan. Anda sebaiknya sering memeriksa daftar grup untuk mencegah hal ini. Gunakan tabel untuk melacak pengguna mana yang berada di setiap grup. Pemodelan data yang baik membantu Anda menemukan masalah sejak dini. Hapus pengguna dari grup yang tidak lagi mereka butuhkan untuk menjaga keamanan data.

Masalah

Solusi

Grup yang tumpang tindih

Periksa daftar grup secara berkala

Akses bayangan

Tinjau anggota grup

Catatan: Akses bayangan dapat menampilkan data pribadi. Perbaiki tumpang tindih grup untuk menjaga sistem Anda tetap aman.

Tinjauan Akses Terjadwal

Anda sebaiknya merencanakan tinjauan akses secara berkala. Periksa siapa saja yang ada di setiap grup dalam interval tertentu. Minta pemilik grup untuk menyatakan siapa yang seharusnya memiliki akses. Hal ini menjaga row-level security dinamis Anda tetap berfungsi seiring pertumbuhan perusahaan. Gunakan alat Fabric untuk membantu pemeriksaan ini. Hapus pengguna lama agar data Anda lebih aman. Hal ini menjaga sistem analitik Anda tetap bersih dan aman. Jadikan tinjauan akses sebagai bagian rutin dari pekerjaan business intelligence Anda.

Peringatan: Tinjauan rutin membantu Anda menemukan kesalahan sebelum menimbulkan masalah.

Resolusi Identitas: Desktop vs. Fabric

Fungsi Identitas dan Perbedaan Cloud

Penting untuk memahami cara kerja identitas di Power BI Desktop dan Microsoft Fabric. Di Power BI Desktop, USERNAME() biasanya menampilkan nama komputer Anda. Di Microsoft Fabric, USERPRINCIPALNAME() memberikan alamat email cloud Anda. Perbedaan ini penting untuk menjaga keamanan data. Jika Anda menggunakan USERNAME() di cloud, orang yang salah bisa melihat data. Selalu gunakan USERPRINCIPALNAME() untuk laporan cloud. Hal ini membantu menjaga keamanan data Anda dan sesuai dengan sistem identitas perusahaan Anda.

Tip: Uji aturan row-level security Anda di cloud. Pengujian di Desktop tidak menampilkan akses pengguna yang sebenarnya.

Pemilik Dataset dan Pengaturan Penyewa

Anda perlu mengetahui siapa pemilik dataset Anda. Pemilik dapat mengubah pengaturan refresh dan memengaruhi siapa yang melihat data. Jika Anda mengganti pemilik, Anda mungkin mengubah siapa yang dapat melihat data pribadi. Pengaturan penyewa juga penting. Pengaturan ini menentukan cara identitas bekerja di perusahaan Anda. Periksa pengaturan penyewa sebelum mempublikasikan laporan. Pastikan model data Anda sesuai dengan kebijakan keamanan perusahaan Anda.

Pengaturan

Dampak pada Keamanan Data

Pemilik Dataset

Mengontrol refresh dan akses

Pengaturan Penyewa

Mengelola organisasi identitas

Penyebab Umum Kebocoran RLS

Anda bisa kehilangan kendali atas row-level security jika tidak menguji di cloud. Terkadang, pengguna melihat lebih banyak data daripada yang seharusnya. Hal ini dapat terjadi jika Anda menggunakan fungsi identitas yang salah atau lupa memperbarui keanggotaan grup. Kebocoran juga dapat terjadi jika Anda mengubah model data tanpa memeriksa tabel keamanan. Selalu tinjau pengaturan keamanan data Anda setelah ada perubahan. Gunakan pengujian cloud dan audit berkala untuk menemukan masalah sejak dini.

Peringatan: Kebocoran keamanan data dapat menampilkan informasi pribadi. Tinjau pengaturan Anda secara berkala untuk menjaga keamanan organisasi Anda.

Pengujian, Audit, dan Tata Kelola

Pengujian RLS Berbasis Cloud

Anda harus menguji keamanan tingkat baris di cloud. Langkah ini memastikan data Anda aman untuk pengguna sungguhan. Fitur "View As" di Desktop hanya menampilkan pratinjau. Fitur tersebut tidak menunjukkan cara aturan bekerja di Microsoft Fabric. Setelah Anda mempublikasikan laporan, uji dengan pengguna dan grup sungguhan. Dengan begitu, Anda dapat melihat data apa saja yang bisa dilihat setiap orang. Gunakan akun uji untuk memeriksa apakah pengguna hanya melihat datanya sendiri. Selalu uji ulang setiap kali Anda mengubah peran atau memperbarui model. Pengujian di cloud membantu Anda menemukan masalah sebelum berdampak pada bisnis.

Tips: Selalu uji dengan pengguna sungguhan di cloud, jangan hanya di Desktop. Langkah ini menjaga keamanan data Anda tetap kuat.

Otomatisasi untuk Audit dan Tinjauan

Anda dapat menggunakan otomatisasi untuk mempermudah audit dan tinjauan di Fabric. Otomatisasi memeriksa izin ruang kerja, alur data, dan label sensitivitas sesuai jadwal. Microsoft Purview menyediakan dasbor untuk memantau aturan di seluruh platform Anda. Anda dapat menggunakan log aktivitas dan Admin API untuk menemukan masalah kepatuhan. Otomatisasi membantu Anda menemukan masalah sejak dini dan menghemat waktu. Auditor dapat melihat jalur lengkap kolom sensitif dari awal hingga laporan. Hal ini membuat tinjauan lebih cepat dan lebih akurat. Otomatisasi juga memudahkan dan menekan biaya untuk mematuhi aturan seperti GDPR dan HIPAA.

Dokumentasi dan Manajemen Perubahan

Anda memerlukan catatan yang baik agar sistem keamanan data tetap jelas. Catat aturan keamanan, daftar grup, dan perubahan peran Anda. Perbarui catatan setiap kali Anda mengubah model atau menambahkan pengguna baru. Catatan yang jelas membantu Anda melacak siapa yang dapat melihat data tertentu. Catatan tersebut juga membantu anggota tim baru mempelajari sistem Anda. Manajemen perubahan berarti Anda memeriksa dan menyetujui pembaruan sebelum diterapkan. Langkah ini menjaga keamanan tingkat baris Anda seiring pertumbuhan perusahaan.

Tugas

Manfaat

Dokumentasikan perubahan

Mencegah kebingungan

Tinjau pembaruan

Memblokir akses yang tidak diinginkan

Lacak penugasan

Membuat data lebih aman

Peringatan: Pastikan catatan Anda selalu mutakhir. Langkah ini melindungi data Anda dan membantu Anda memperbaiki masalah dengan cepat.

Anggap keamanan tingkat baris sebagai sesuatu yang terus berubah seiring pertumbuhan data dan perusahaan Anda. Pengaturan yang baik membantu menjaga informasi pribadi tetap aman. Menggunakan pola DAX yang baik dan mengelola identitas pengguna dengan baik akan melindungi data Anda. Memeriksa keamanan dan mencatat perubahan membantu Anda mendeteksi masalah sejak dini. Jika Anda merencanakan dengan matang, Anda dapat mengontrol siapa yang melihat data dan menjaga analitik Anda tetap aman.

Pertanyaan Umum

Apa itu keamanan tingkat baris dinamis di Power BI dan Fabric?

Keamanan tingkat baris dinamis memungkinkan Anda mengontrol akses data berdasarkan siapa yang melihat laporan. Anda menggunakan fungsi DAX dan tabel pemetaan untuk mencocokkan pengguna dengan data yang tepat.

Mengapa Anda sebaiknya menggunakan USERPRINCIPALNAME() dan bukan USERNAME()?

USERPRINCIPALNAME() memberikan email cloud pengguna. Fungsi ini paling sesuai untuk Power BI dan Fabric. USERNAME() mungkin menampilkan nama lokal, yang dapat menimbulkan masalah keamanan di cloud.

Bagaimana grup Azure AD membantu keamanan?

Grup Azure AD memungkinkan Anda mengelola akses untuk banyak pengguna sekaligus. Anda menambahkan pengguna ke grup dan menetapkan peran. Hal ini membuat pengaturan keamanan Anda lebih mudah dan lebih aman.

Apa itu tabel keamanan, dan mengapa Anda memerlukannya?

Tabel keamanan berisi daftar pengguna, grup, dan izin. Anda menggunakannya untuk mengontrol siapa yang dapat melihat data tertentu. Hal ini membantu Anda menjaga keamanan data seiring pertumbuhan perusahaan.

Seberapa sering Anda harus menguji keamanan tingkat baris di cloud?

Anda harus menguji keamanan tingkat baris setiap kali mengubah peran, grup, atau model data. Pengujian di cloud menunjukkan apa yang dapat dilihat pengguna sungguhan dan membantu Anda menemukan masalah sejak dini.

Microsoft Fabric Governance Power BI

Related articles

RSS