Belajar Data Architect - Security & Privacy Data

#Pendahuluan

Setelah di episode 9 kita memastikan data berkualitas, sekarang kita membahas sisi yang tidak boleh kalah: keamanan dan privasi. Kebocoran data bukan sekadar insiden teknis — ia adalah insiden hukum, reputasi, dan kepercayaan. Dan ketika data melintasi pipeline, lakehouse, dan dashboard, permukaan serangan pun bertambah.

Mengapa episode ini penting? Karena keamanan data adalah tanggung jawab desain, bukan tempelan. Fitur keamanan yang dipasang setelah sistem berjalan selalu lebih mahal dan lebih mudah salah. Arsitek yang memasukkan security ke dalam blueprint sejak awal menyelamatkan organisasi dari biaya remediation yang puluhan kali lipat.

#Model Zero Trust untuk Data

Prinsip Zero Trust: jangan percaya siapa pun secara default — setiap akses harus diverifikasi dan diberi hak minimum. Berlaku pada jaringan, identitas, dan data. Kita bedah detail di episode 18; untuk sekarang pahami tiga aspek inti:

1. Never trust, always verify   → setiap akses diverifikasi identitas & konteks
2. Least privilege              → beri akses seminimal mungkin yang dibutuhkan
3. Assume breach                → rancang seolah-olah sudah ada yang masuk

#Enkripsi Data

#At-Rest

Data yang disimpan harus dienkripsi. Di platform modern ini hampir selalu bawaan (encryption by default di S3/GCS, BigQuery, Snowflake), tapi arsitek harus menegakkan dan memverifikasinya:

- Object storage: SSE (server-side encryption) aktif, KMS terkelola
- Warehouse/lakehouse: encryption enabled, key rotation terjadwal
- Backup: dienkripsi juga, jangan hanya data utama
- Kunci: simpan di KMS/HSM terpusat, jangan di env var app

#In-Transit

Semua jalur data wajib TLS. Ini mencakup koneksi aplikasi ke database, pipeline ke warehouse, dan API antar sistem. Arsitek menetapkan standar: TLS 1.3 minimum, sertifikat valid, dan mTLS untuk layanan internal yang sensitif.

#Data Masking dan Tokenization

Tidak semua orang butuh melihat data asli. Masking menggantikan nilai sensitif dengan nilai samaran:

Implementasi masking di SQL:

CREATE FUNCTION mask_phone(p VARCHAR) RETURNS VARCHAR
AS 'SELECT CONCAT(LEFT(p, 4), ''-XXXX-XXXX'')'
LANGUAGE SQL IMMUTABLE;
 
-- dipakai saat menampilkan ke role non-privileged
SELECT mask_phone(customer_phone) FROM customer;

Prinsip: data asli disimpan sekali di trusted zone; masking diterapkan di lapisan konsumsi sesuai role.

#RBAC: Role-Based Access Control

RBAC adalah model kontrol akses paling umum: pengguna → role → permission. Arsitek merancang role hierarchy yang stabil:

roles:
  data_engineer    → read/write bronze & silver, kelola pipeline
  data_analyst     → read gold, read selected silver
  data_scientist   → read gold + ML datasets, tulis sandbox
  data_steward     → kelola metadata, approve akses
  dba              → admin platform, backup, tuning

Aturan penting:

• Hak default = tidak ada; setiap akses diminta dan disetujui.
• Privilege diangkat (episode 18): akses temporary untuk tugas spesifik, lalu dicabut.
• Segregasi tugas: orang yang menulis data tidak sama dengan yang mengapprove akses.

#GDPR dan Privasi

GDPR (EU General Data Protection Regulation) adalah standar global untuk perlindungan data pribadi. Prinsip-prinsip yang memengaruhi arsitektur:

Implikasi arsitektur paling konkret: purge pipeline. Saat user meminta penghapusan data, arsitektur harus tahu di mana saja data orang itu berada — dari bronze, silver, gold, sampai log pipeline — dan bisa menghapusnya.

#Praktik: Menyusun Security Blueprint

Blueprint adalah dokumen yang menjawab: siapa bisa mengakses apa, dengan cara apa, dan apa yang tercatat. Struktur minimal:

1. Aset data & klasifikasi (public, internal, confidential, restricted)
2. Peta akses: role → dataset → mode (read/write/admin)
3. Enkripsi: at-rest & in-transit, key management, rotation
4. Masking & tokenization untuk PII per lapisan
5. RBAC + privilege elevation flow + approval workflow
6. Audit: apa yang dilog, berapa lama disimpan
7. Incident response: siapa dipanggil saat breach terdeteksi

Langkah penyusunan:

1. Klasifikasikan data — PII, finansial, kesehatan masuk restricted.
2. Petakan akses sesuai kebutuhan riil tiap role.
3. Tetapkan enkripsi dan key rotation schedule.
4. Definisikan audit trail — termasuk akses yang gagal (sering diabaikan tapi justru paling penting untuk deteksi).
5. Review kuartalan — role berubah, orang keluar, data baru masuk.

#Penutup

Inti yang harus dibawa pulang:

• Keamanan adalah desain, bukan tempelan; terapkan zero trust sejak awal.
• Enkripsi at-rest + in-transit wajib di seluruh lapisan, termasuk backup.
• Masking/tokenization menjaga PII di lapisan konsumsi; data asli di trusted zone.
• RBAC dengan least privilege dan privilege elevation.
• GDPR menuntut data minimization, purge pipeline, dan privacy by design.
• Security blueprint menjawab siapa-akses-apa secara terdokumentasi dan ter-review.

Di episode 11 selanjutnya kita akan membahas Semantic Layer & Metrics Store — bagaimana satu definisi metrik bisa dipakai konsisten oleh semua dashboard, BI, dan AI. Sampai jumpa di episode 11!