Mengimplementasikan Dynamic Row-Level Security di Power BI dan Microsoft Fabric: Arsitektur, Pola DAX, dan Tata Kelola Tingkat Enterprise
By Mirko Peters · · 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
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 |
|---|---|
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
Dynamic Row-Level Security menyesuaikan diri dengan kebutuhan perusahaan Anda. Fitur ini memungkinkan Anda memilih siapa yang dapat melihat data tertentu dengan memeriksa identitas setiap pengguna.
Gunakan USERPRINCIPALNAME() untuk keamanan di cloud. Fungsi ini memastikan pengguna hanya melihat data miliknya sendiri. Dengan begitu, informasi Anda tetap terlindungi.
Periksa pengaturan keamanan dan grup pengguna secara berkala. Langkah ini mencegah orang melihat data yang seharusnya tidak mereka akses. Hal ini membantu menjaga keamanan data Anda.
Buat tabel keamanan yang jelas untuk mengelola izin pengguna. Dengan cara ini, Anda dapat mengontrol siapa yang melihat apa seiring perusahaan Anda berkembang.
Uji aturan keamanan Anda di cloud dengan pengguna sungguhan. Langkah ini memastikan data Anda aman dan hanya dapat dilihat oleh pengguna sesuai izin mereka.
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.
Static row-level security menggunakan aturan tetap untuk membatasi data.
Dynamic row-level security mengubah data yang dilihat pengguna berdasarkan identitas mereka.
Dynamic security paling cocok untuk perusahaan besar dengan banyak aturan.
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.
Filter baris membantu membatasi apa yang dapat dilihat pengguna. Anda dapat memblokir data berdasarkan wilayah, departemen, atau akun.
Topeng kolom (column mask) memungkinkan Anda menyembunyikan atau mengubah data berdasarkan siapa penggunanya.
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:
Menggunakan USERNAME() di cloud.
Menulis email atau domain pengguna secara hardcode.
Menempatkan logika keamanan di kolom kalkulasi.
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.
Buat tabel keamanan dengan kolom yang jelas untuk pengguna dan izin.
Pisahkan peran agar tidak tumpang tindih dan menimbulkan masalah.
Periksa tabel keamanan Anda secara berkala untuk mengikuti perubahan.
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.
Tentukan tanggal untuk meninjau semua grup.
Gunakan alat Fabric untuk membantu memeriksa grup.
Minta pemilik untuk mengonfirmasi siapa saja yang ada di setiap grup.
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.
Atur pemeriksaan otomatis untuk izin dan alur data.
Gunakan dasbor untuk memantau perubahan pada aturan keamanan.
Periksa log aktivitas untuk menemukan masalah dengan cepat.
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.
Periksa pengaturan keamanan Anda secara rutin.
Gunakan aturan yang berubah untuk melindungi data dengan lebih baik.
Selalu utamakan privasi.
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.