Mengamankan Portal Power Pages Anda: Pembahasan Mendalam tentang Izin Tabel dan Cakupan

By Mirko Peters · 2026-08-11

Selamat datang kembali di blog podcast! Saat membangun aplikasi web berbasis pelanggan di Microsoft Power Platform, keamanan tidak boleh dipikirkan belakangan. Power Pages adalah alat yang luar biasa untuk menerapkan portal eksternal yang andal dengan cepat dan terhubung langsung ke Dataverse. Namun, kekuatan besar datang dengan tanggung jawab besar, khususnya tanggung jawab untuk memastikan data

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

Titelbild: Securing Your Power Pages Portal: A Deep Dive into Table Permissions and Scopes

Dalam artikel ini, kita akan membahas secara mendalam konsep inti arsitektur keamanan yang kita bahas di episode terbaru kami. Jika Anda belum mendengarkannya, pastikan Anda menyimak episode Build Customer Portals with Power Pages and Dataverse untuk panduan lengkap mengatur lingkungan, menangani identitas eksternal, dan menerapkan solusi portal pertama Anda.

Mari kita telusuri mekanisme keamanan Power Pages secara mendalam, dimulai dengan cara merencanakan batas data dan menguasai Izin Tabel.

Pengantar Keamanan Power Pages

Saat pertama kali membuat situs Power Pages, platform ini menyediakan kanvas yang fleksibel dan sangat dapat disesuaikan. Namun di balik kanvas tersebut terdapat jalur langsung ke lingkungan Microsoft Dataverse Anda. Jika konfigurasi keamanan Anda salah kelola, setiap rekaman di basis data Anda berpotensi terekspos melalui endpoint yang tidak aman atau tampilan daftar dengan cakupan yang buruk.

Keamanan di Power Pages mengandalkan strategi pertahanan berlapis. Di lapisan luar, terdapat mekanisme autentikasi, seperti Azure AD B2C, akun lokal, atau penyedia identitas eksternal, yang memastikan pengguna membuktikan siapa mereka. Di lapisan dalam, terdapat Peran Web dan Izin Tabel Dataverse. Izin ini menentukan dengan tepat apa yang dapat dilihat, dibuat, diperbarui, atau dihapus oleh identitas yang telah terautentikasi. Ketepatan dalam hal ini menentukan apakah Anda memiliki portal perusahaan yang aman atau justru menunggu terjadinya pelanggaran data besar.

Merencanakan Batas Data dan Izin Tabel Anda

Sebelum Anda menyentuh satu tombol pun di Power Pages Studio, Anda perlu mengambil papan tulis dan memetakan batas data Anda dengan cermat. Ini bisa dibilang 15 menit paling krusial dalam seluruh siklus proyek portal Anda.

Mulailah dengan membuat inventaris lengkap setiap tabel Dataverse yang ingin Anda ekspos kepada pengguna eksternal. Untuk setiap tabel, tentukan tindakan CRUD minimum yang benar-benar diperlukan. Apakah pelanggan benar-benar perlu dapat menghapus faktur, atau cukup memiliki akses Baca dan Tambah saja? Setelah Anda menentukan tindakan, Anda harus menentukan cakupan baris untuk setiap tabel:

Cakupan Kontak: Pengguna hanya dapat berinteraksi dengan rekaman yang terkait langsung dengan rekaman Kontak mereka.
Cakupan Akun: Pengguna dapat berinteraksi dengan rekaman yang terkait dengan seluruh perusahaan atau Akun mereka.
Cakupan Global: Pengguna dapat melihat seluruh rekaman di seluruh tabel (biasanya diperuntukkan bagi artikel Basis Pengetahuan publik atau metadata).

Dengan memetakan batas-batas ini sejak awal, Anda menetapkan dasar hak akses minimum sebelum konfigurasi apa pun dibuat di lingkungan pengembangan Anda.

Memahami Cakupan Kontak vs. Akun

Salah satu kebingungan paling umum bagi pembuat yang baru mengenal Power Pages adalah memahami perbedaan halus antara cakupan Kontak dan Akun. Memilih cakupan yang keliru dapat sepenuhnya merusak pengalaman pengguna dengan menyembunyikan data perusahaan yang relevan, atau secara tidak sengaja membuka data rahasia kepada individu yang tidak berwenang.

Cakupan Kontak dirancang untuk portal individual bergaya konsumen. Jika pengguna masuk dan mengirimkan tiket dukungan, izin dengan cakupan Kontak memastikan mereka hanya dapat melihat kasus yang secara eksplisit tercantum sebagai kontak utama atau pembuatnya. Jika pengguna lain dari perusahaan yang sama masuk, mereka tidak akan melihat tiket dukungan pribadi rekannya.

Di sisi lain, Account Scope dirancang untuk arsitektur portal B2B. Dalam skenario B2B, Anda ingin Account Manager atau petugas pengadaan utama dapat melihat semua kasus, pesanan, dan faktur yang terkait dengan induk akun perusahaan mereka. Saat Anda menetapkan scope Account ke Table Permission, portal mengevaluasi akun induk yang terhubung dengan rekaman Contact pengguna yang sedang login, lalu menampilkan semua rekaman anak yang termasuk dalam organisasi tersebut. Memetakan relasi ini dengan benar di Dataverse sangat penting untuk keberhasilan B2B.

Mendefinisikan Web Role dan Menghindari Jebakan Authenticated Users

Web Role adalah jembatan antara pengguna yang telah terautentikasi dan Table Permission di Dataverse. Secara default, Power Pages menyediakan role bawaan bernama "Authenticated Users". Di sinilah banyak administrator terjebak dalam perangkap keamanan yang berbahaya.

Secara default, setiap pengguna yang berhasil login ke portal Anda otomatis masuk ke role Authenticated Users. Jika Anda menambahkan table permission yang luas, atau lebih buruk lagi, permission dengan scope Global, ke role default ini, setiap orang yang mendaftar di situs Anda akan langsung mewarisi hak akses yang terbuka lebar tersebut. Ini adalah anti-pattern keamanan yang sangat serius.

Sebagai gantinya, buatlah Web Role khusus dan granular yang disesuaikan dengan persona pengguna Anda. Misalnya:

CustomerUser: Dipetakan ke scope Contact untuk tabel operasional seperti Cases dan Orders, sehingga pengguna dapat memantau interaksi mereka sendiri.
AccountManager: Dipetakan ke scope Account, memberikan pimpinan organisasi yang ditunjuk visibilitas atas aset di seluruh perusahaan.
KnowledgeBaseViewer: Dipetakan secara global, tetapi dibatasi ketat hanya untuk aksi Read-only pada artikel dukungan yang bersifat publik.

Selalu hapus akses default yang tidak diperlukan dan pastikan pengguna secara eksplisit ditetapkan ke role yang dirancang khusus berdasarkan hubungan organisasi mereka.

Memperkuat Visibilitas Tingkat Field dan Melindungi PII

Mengontrol akses tingkat baris melalui table scope hanyalah separuh dari pekerjaan. Anda juga perlu cermat memperhatikan data apa saja yang terlihat di dalam setiap baris dan daftar. Mengekspos Personally Identifiable Information (PII) seperti nomor telepon, alamat rumah, detail keuangan, atau catatan internal karyawan dapat menyebabkan pelanggaran kepatuhan yang serius (seperti kegagalan GDPR atau CCPA).

Saat membangun daftar dan formulir dasar di Power Pages, pastikan Anda membersihkan view dari kolom-kolom sensitif. Hanya karena sebuah field disembunyikan pada tata letak formulir di sisi depan tidak berarti field tersebut tidak dapat diperiksa atau diambil melalui web API yang mendasarinya jika permission-nya terlalu luas. Gunakan view khusus yang diperkuat (misalnya "PublicView") yang hanya berisi kolom yang aman dan sudah disanitasi. Jika kolom tertentu harus tetap berada di tabel database, pertimbangkan untuk menerapkan column-level security di Dataverse guna sepenuhnya membatasi akses di tingkat mesin database.

Menguji Penetrasi Permission Portal Anda

Anda tidak bisa begitu saja berasumsi bahwa model keamanan Anda berfungsi; Anda harus membuktikannya. Sebelum mempromosikan solusi portal apa pun ke lingkungan uji atau produksi, Anda perlu melakukan penetration testing yang ketat terhadap table permission dan logika routing Anda.

Siapkan akun pengguna uji untuk setiap Web Role yang telah Anda definisikan. Login sebagai CustomerUser standar dan coba lihat data milik Contact atau Account lain. Coba manipulasi URL langsung dan pemalsuan GUID dengan mengganti ID rekaman di address bar browser, untuk memastikan server benar-benar memblokir permintaan yang tidak sah. Selain itu, tinjau diagnostic dan audit log portal Anda untuk memverifikasi bahwa upaya eskalasi hak akses memicu respons 403 Forbidden yang sesuai.

Kesimpulan dan Praktik Terbaik

Mengamankan portal Power Pages membutuhkan perencanaan yang matang, kepatuhan ketat terhadap prinsip least privilege, serta pemahaman mendalam tentang table permission dan scope di Dataverse. Dengan meninggalkan default berbahaya seperti role Authenticated Users, membatasi akses tabel secara cermat pada level Contact atau Account, dan memperkuat visibilitas tingkat field, Anda dapat membangun portal pelanggan yang sangat fungsional sekaligus sangat aman.

Untuk mendalami topik ini lebih jauh dan melihat panduan implementasi lengkap dari awal hingga akhir, termasuk pengaturan identitas eksternal, perancangan arsitektur solusi, dan persiapan menjelang go-live, dengarkan episode podcast pendamping kami: Build Customer Portals with Power Pages and Dataverse. Terima kasih telah membaca, dan nantikan tips ahli lainnya untuk menguasai Microsoft Power Platform!