Belajar BI Analyst - Data Security & Row-Level Security

#Pendahuluan

Semakin banyak orang yang memakai data kalian (self-service di episode 13), semakin besar risiko: tidak semua orang berhak melihat semua data. Analis sales tidak seharusnya melihat margin per transaksi seluruh region; karyawan HR tidak seharusnya melihat data gaji; dan akun yang dipakai demo tidak boleh mengakses data produksi.

Episode ini membahas data security dari sudut pandang BI Analyst: bagaimana memastikan setiap pengguna hanya melihat data yang memang berhak mereka lihat — lewat row-level security (RLS), role-based access, dan data masking. Ini bukan sekadar teknis; ini fondasi kepercayaan dan kepatuhan hukum.

#Level Keamanan Data di BI

Keamanan data berlapis, dan kalian harus memahami di lapisan mana tiap kontrol bekerja:

Konsep kuncinya: defense in depth — jangan bergantung pada satu lapisan. Dashboard tanpa akses di level database hanyalah ilusi keamanan.

#Row-Level Security (RLS)

RLS membatasi baris data yang bisa dilihat pengguna berdasarkan aturan. Contoh paling umum di dunia BI: analis sales regional hanya melihat data regionnya sendiri.

#RLS di Database (PostgreSQL)

Implementasi paling murni ada di database — kendali tidak bisa dilewati tool apa pun:

CREATE POLICY region_isolation ON fact_orders
    USING (region = current_setting('app.region', true));
 
ALTER TABLE fact_orders ENABLE ROW LEVEL SECURITY;
 
-- Peran analis regional
CREATE ROLE analyst_west;
GRANT SELECT ON fact_orders TO analyst_west;
 
-- Setiap sesi menetapkan region-nya
SET app.region = 'West';

Dengan policy ini, koneksi sebagai analyst_west hanya bisa melihat baris region = 'West' — meskipun query menulis SELECT * FROM fact_orders. Inilah RLS yang tidak bisa diakali.

#RLS di Power BI

Power BI menerapkan RLS di level model — cocok untuk pengguna yang tidak punya akses database langsung. Buat peran dan DAX filter:

# Manage Roles → New Role
Role: Regional Manager
DAX filter: [region] = LOOKUPVALUE(dim_customer[region], dim_customer[region], USERPRINCIPALNAME())

USERPRINCIPALNAME() mengambil email pengguna yang sedang login — lalu mencocokkan ke region miliknya. Saat user membuka report, mereka hanya melihat data regionnya.

#RLS di Tableau dan Looker

• Tableau: buat per-user filter lewat USERNAME()/CURRENT_USER() di calculated field, lalu gabungkan dengan data user-mapping.
• Looker: access_filter di LookML — misalnya field region dibatasi sesuai user attribute:

access_filter: {
    field: orders__region
    user_attribute: user_region
}

Prinsipnya sama di semua tool: kunci pengguna → atribut pengguna → filter baris otomatis. Nama fungsinya beda, konsepnya identik.

#Role-Based Access Control (RBAC)

Jika RLS membatasi baris, RBAC membatasi fitur dan data apa yang boleh diakses siapa. Di tool BI, contohnya:

Prinsip least privilege: beri akses minimum yang dibutuhkan untuk bekerja. Mulai dari viewer, naikkan hanya saat dibutuhkan. Audit akses secara berkala — akun karyawan yang sudah keluar sering menjadi lubang keamanan yang terlupakan.

#Data Masking: Menyembunyikan Data Sensitif

Data masking menampilkan data dengan versi tersamarkan — bukan menghapus, tetapi menyembunyikan. Contohnya:

Teknik masking:

• Partial masking: tampilkan sebagian (mis. 4 digit terakhir).
• Aggregation/rounding: tampilkan rentang, bukan angka presisi (mis. "12-13 juta").
• Nullification: sembunyikan total untuk data sangat sensitif.

Masking paling efektif dilakukan di semantic layer: kalian mendefinisikan kolom mana yang boleh dilihat peran mana. Tool BI modern punya fitur object-level security (mis. Power BI OLS) untuk menyembunyikan kolom sensitif dari peran tertentu.

#Praktik: Setup RLS Superstore

Terapkan RLS untuk skenario nyata: empat regional manager, masing-masing hanya melihat regionnya.

1. Di database: buat peran analyst_west, analyst_east, dll. plus RLS policy region_isolation seperti contoh di atas.
2. Di tool BI: buat peran "Regional Manager" dengan filter region dari user mapping.
3. Uji dengan dua akun: buka dashboard sebagai user region West → hanya data West yang muncul. Coba paksa akses region lain → ditolak.
4. Dokumentasikan: tulis siapa dapat role apa, kapan terakhir diaudit.

Uji RLS ini wajib — keamanan yang tidak diuji adalah dugaan.

#Kesalahan Umum Data Security

• Mengandalkan RLS di tool saja: pengguna dengan akses langsung ke database bisa melewatinya — pasang juga di database.
• Akses admin terlalu longgar: least privilege, audit rutin, nonaktifkan akun yang tidak terpakai.
• Masking yang tidak konsisten: kolom sensitif tersembunyi di satu dashboard, muncul di dashboard lain.
• Mengirim dashboard berisi data sensitif ke grup yang salah: selalu cek penerima sebelum share.
• Tanpa uji keamanan: asumsi "seharusnya tidak bisa lihat" berbeda dengan fakta "tidak bisa lihat".

#Penutup

Inti yang harus dibawa pulang:

• Keamanan BI berlapis (defense in depth): database → semantic layer → tool → dashboard.
• RLS membatasi baris per pengguna; implementasikan di database (paling kuat) dan di tool BI.
• RBAC (least privilege) membatasi peran dan fitur; data masking menyembunyikan data sensitif.
• Semua teknik mengikuti pola yang sama: kunci pengguna → atribut → filter otomatis.
• Praktik: RLS empat regional manager Superstore berhasil diuji di database dan tool BI.

Di episode 19 selanjutnya kita akan membahas privacy & compliance BI — GDPR, penanganan PII, dan audit trail, plus praktik membangun compliance report. Keamanan yang baik dilengkapi kepatuhan hukum yang benar. Pastikan tetap semangat!