Belajar Data Architect - Zero Trust untuk Data

#Pendahuluan

Setelah di episode 17 kita menetapkan blueprint enterprise, sekarang kita kembali ke keamanan — tapi kali ini lebih dalam: Zero Trust untuk data. Di episode 10 kita menyentuh prinsipnya; sekarang kita bedah bagaimana mengimplementasikannya secara konkret pada akses data.

Mengapa episode ini penting? Karena model keamanan tradisional ("di dalam jaringan = aman") sudah tidak berlaku: data sekarang di cloud, diakses dari mana saja, oleh tim internal, vendor, dan AI agent. Zero Trust menggeser fondasi dari di mana akses datang menjadi siapa dan dalam konteks apa.

#Dari Network-Centric ke Identity-Centric

Model lama: keamanan berbasis perimeter — kalau sudah masuk VPN/network, bebas mengakses. Model Zero Trust: setiap permintaan akses data diverifikasi secara independen, tidak peduli dari mana datangnya.

LAMA:  "Sudah di jaringan internal → percaya → akses luas"
BARU:  "Setiap akses → verifikasi identitas + konteks → keputusan
        per-permintaan, hak minimum, akses dicabut otomatis"

Pilar Zero Trust untuk data:

1. Identity-driven: identitas (bukan IP) adalah dasar keputusan.
2. Least privilege: akses seminimal yang dibutuhkan pekerjaan.
3. Contextual: keputusan mempertimbangkan konteks (waktu, lokasi, device, risiko).
4. Dynamic: akses bisa berubah sesuai kondisi (privilege elevation, sesi).
5. Audit penuh: setiap keputusan dan akses tercatat.

#PDP dan PEP: Memisahkan Keputusan dari Eksekusi

Arsitektur kontrol akses modern memisahkan dua tanggung jawab:

Mengapa pemisahan ini penting? Karena policy dikelola terpusat di PDP (sekali diubah, berlaku di semua resource), sementara enforcement terjadi lokal di setiap resource (PEP). Tanpa pemisahan, policy tersebar di ratusan tempat dan tidak konsisten.

Implementasi praktis: Open Policy Agent (OPA) adalah contoh PDP paling umum — policy ditulis sebagai kode (Rego), di-version, dan diuji:

package data.access
 
default allow := false
 
allow if {
    input.subject.role == "data_analyst"
    input.resource.domain == "sales"
    input.action == "read"
    not input.resource.tier == "restricted"
}

Satu PDP, banyak resource: database, object storage, BI, dan API semuanya bisa ditanya ke engine yang sama.

#RBAC vs ABAC vs ReBAC

Tiga model kontrol akses yang sering dicampur aduk:

Perbandingan praktis:

USER: analyst Andi, region Jakarta, role data_analyst
DATA: dataset sales_revenue, tier internal, region Jakarta
 
RBAC:  Andi role analyst → boleh baca sales?       YA (role cocok)
ABAC:  analyst + region Jakarta cocok + jam kerja → YA
       analyst + region Surabaya (bukan tugasnya)  → TIDAK
ReBAC: Andi punya relasi "assigned_to" region →    YA

ABAC adalah pilihan umum untuk data karena granular: keputusan bisa memakai atribut seperti region, klasifikasi data, waktu, dan approval. Ini yang kita pakai untuk contoh di bawah.

#Praktik: Desain Access Control untuk Data

#Step 1: Definisikan Atribut

USER:     role, region, department, level, employment_status
RESOURCE: domain, tier (public/internal/restricted), owner, pii_flag
CONTEXT:  waktu, device, lokasi, approval_status

#Step 2: Tulis Policy ABAC

1. data_analyst  → baca data tier internal domain miliknya, region sesuai
2. data_scientist → baca gold + sandbox ML, tanpa PII (kecuali approval)
3. auditor       → baca semua metadata + audit log, bukan data transaksional
4. AI agent      → baca terbatas, tanpa PII, sesi di-log & terbatas waktu
5. semua        → akses restricted butuh approval + tercatat

#Step 3: Terapkan di Lapisan

- Database/warehouse: row-level security / masking sesuai atribut user
- Object storage: policy bucket berbasis atribut
- BI: permission pada dataset + row-level di dashboard
- API data: middleware yang bertanya ke PDP sebelum meneruskan

#Step 4: Uji dan Audit

Uji dengan skenario: user normal, user berubah region, mantan karyawan (akses dicabut), dan AI agent. Semua keputusan di-log untuk audit (episode 20).

#Penutup

Inti yang harus dibawa pulang:

• Zero Trust memindahkan kepercayaan dari jaringan ke identitas + konteks.
• PDP/PEP: policy terpusat di decision point, enforcement di setiap resource.
• RBAC untuk role statis, ABAC untuk atribut/kondisi, ReBAC untuk relasi.
• ABAC cocok untuk data: keputusan bisa memakai region, tier, waktu, approval.
• Terapkan bertahap: mulai dari PII, uji skenario, dan audit semua keputusan.

Di episode 19 selanjutnya kita akan membahas Regulatory Compliance Data — GDPR, AI Act, data residency, dan kesiapan audit dalam desain arsitektur. Sampai jumpa di episode 19!