Security & Access Control

#Pendahuluan

Pipeline data mengangkut aset paling berharga perusahaan: data pelanggan, transaksi, dan rahasia internal. Satu celah keamanan bisa berarti kebocoran data massal, denda regulasi, dan hilangnya kepercayaan publik.

Di episode ini kita akan membahas empat pilar keamanan yang wajib dipahami data engineer: authentication (siapa kalian), authorization (apa yang boleh dilakukan), enkripsi (perlindungan data saat disimpan dan dikirim), serta secret management (pengelolaan kredensial).

#Authentication: Siapa yang Mengakses?

Authentication memverifikasi identitas sebelum akses diberikan. Di ekosistem data, identitas bisa datang dari:

IAM user/role (AWS, GCP, Azure) untuk layanan dan manusia
Service account khusus untuk aplikasi dan pipeline
SSO / OIDC supaya karyawan masuk lewat penyedia identitas perusahaan
Service-to-service lewat OAuth 2.0 atau mutual TLS

Praktik terbaik yang berlaku universal: identitas berbasis role dan workload daripada akun pribadi, dan kebijakan least privilege — beri akses seminimal mungkin.

contoh akses lewat role (AWS CLI)

# pipeline memakai role khusus, bukan kredensial root
aws sts assume-role --role-arn arn:aws:iam::123456789012:role/dbt-runner \
  --role-session-name etl-batch

Jangan pakai kredensial pribadi di pipeline

Akun root, akses key manusia, atau password database yang dipakai langsung di script adalah sumber utama kebocoran. Selalu gunakan peran jangka pendek (short-lived credentials) yang di-rotate otomatis.

#Authorization: Apa yang Boleh Dilakukan?

Setelah identitas terverifikasi, authorization menentukan batasannya. Di dunia data, model yang paling umum adalah RBAC (Role-Based Access Control) dan ABAC (Attribute-Based Access Control).

RBAC mengelompokkan hak akses ke role: misalnya analyst hanya boleh SELECT, ingestion hanya boleh INSERT ke tabel mentah, dan admin boleh semuanya.

contoh grant role di database

CREATE ROLE data_analyst;
GRANT SELECT ON SCHEMA dwh TO data_analyst;
 
CREATE ROLE etl_runner;
GRANT SELECT, INSERT ON SCHEMA staging TO etl_runner;
GRANT SELECT, UPDATE ON SCHEMA transform TO etl_runner;

Tingkatan kontrol akses

Kontrol akses tidak berhenti di database. Terapkan juga di file/object storage (S3, GCS), warehouse (BigQuery, Snowflake), dan tooling (Airflow, dbt). Prinsipnya sama: sesuaikan hak akses dengan kebutuhan kerja — least privilege.

#Enkripsi: Data Terlindungi di Semua Titik

Enkripsi dibagi menjadi dua kategori besar:

In transit: data terlindungi saat bergerak antar layanan, menggunakan TLS.
At rest: data terlindungi saat disimpan, menggunakan AES-256 dengan kunci yang dikelola.

Di cloud, enkripsi at rest biasanya aktif secara default untuk layanan managed. Yang sering terlewat adalah data internal di dalam tabel, seperti kolom PII atau nomor kartu, yang bisa dilindungi dengan enkripsi kolom, tokenization, atau masking.

contoh enkripsi kolom di Postgres

CREATE EXTENSION IF NOT EXISTS pgcrypto;
 
INSERT INTO customers (email_encrypted)
VALUES (
  pgp_sym_encrypt('user@example.com', current_setting('app.enc_key'))
);

Kunci enkripsi sebaiknya disimpan di KMS (misal AWS KMS atau GCP KMS), bukan di database atau kode. Rotasi kunci otomatis, akses kunci dipantau, dan audit trail tercatat — ini juga syarat umum kepatuhan.

#Secret Management: Kredensial yang Terkelola

Kredensial database, API key, dan token harus disimpan di secret manager khusus, bukan di environment variable yang di-commit ke git atau menempel di file pipeline.

Beberapa opsi populer: AWS Secrets Manager, GCP Secret Manager, HashiCorp Vault, dan Doppler. Pipeline CI/CD mengunduh secret dari sini saat runtime, bukan menyimpannya di image.

contoh ambil secret dari Vault

export DB_PASSWORD=$(
  vault kv get -field=password secret/warehouse/postgres
)
 
docker run --env DB_PASSWORD="$DB_PASSWORD" dbt-runner

Kesalahan fatal yang harus dihindari

Jangan pernah: meng-commit .env berisi secret ke git, menyimpan password di image Docker, atau menaruh token di URL. Satu commit ceroboh dan secret langsung terekspos. Gunakan pemindai secret (misal gitleaks atau trufflehog) di pre-commit dan CI.

#Praktik untuk Pipeline Data

Sebuah pipeline yang aman setidaknya menerapkan pola berikut:

checklist keamanan pipeline

- Identitas unik per pipeline (service account / workload identity)
- Least privilege di database, storage, dan tooling
- Enkripsi at rest + in transit di setiap layer
- Secret di secret manager, diambil saat runtime
- Audit log untuk siapa mengakses data apa dan kapan
- Network boundary: private subnet, VPC peering, tidak ekspos database ke publik

#Penutup

Keamanan data bukan tugas terpisah, melainkan bagian dari cara kerja sehari-hari. Authentication memastikan yang masuk adalah yang berhak, authorization membatasi ruang geraknya, enkripsi melindungi data di mana pun berada, dan secret management memastikan kredensial tidak bocor.

Dengan pondasi keamanan yang kuat, data engineer bisa membangun sistem yang tidak hanya cepat dan benar, tetapi juga dapat dipercaya. Di episode berikutnya kita akan membahas Data Privacy & Compliance — aturan yang mengatur bagaimana data pribadi boleh digunakan.