Belajar Vitess - Access Control & Audit

#Pendahuluan

Keamanan tidak berhenti di enkripsi. Setelah kalian mengunci jalur transport di episode 12, pertanyaan berikutnya: siapa yang boleh melakukan apa? Tidak semua user harus bisa DROP TABLE, dan tidak semua query harus dicatat. Episode 13 membahas model akses dan jejak audit di Vitess — lapisan yang menentukan siapa bisa masuk dan apa yang bisa mereka lakukan.

Roadmap episode 13: user dan privileges MySQL, akses row dan column-level, audit logging, lalu pemisahan akses aplikasi dan admin tools.

#User dan Privileges MySQL di Vitess

Model akses Vitess bertumpu pada user MySQL. Setiap user punya grants: tabel mana yang boleh dibaca, tabel mana yang boleh ditulis, dan operasi admin apa yang boleh dijalankan. Kunci untuk mengelola ini dengan aman: buat user dengan prinsip least privilege.

Beberapa peran yang biasa dipakai:

• Aplikasi (appuser) — hanya SELECT, INSERT, UPDATE, DELETE pada tabel aplikasi. Tidak butuh DDL.
• Schema change (ddluser) — punya ALTER, CREATE, DROP, hanya dipakai saat migrasi.
• Read-only (readonlyuser) — hanya SELECT, untuk reporting.
• Admin (root) — akses penuh, hanya untuk operator.

CREATE USER 'appuser'@'%' IDENTIFIED BY 'rahasia'
GRANT SELECT, INSERT, UPDATE, DELETE ON commerce.* TO 'appuser'@'%'

Perintah GRANT di atas memberi appuser kemampuan tulis-baca tanpa hak DDL. Setiap user sebaiknya punya password berbeda dan dirotasi berkala.

#Row dan Column-level Access

Terkadang membatasi per tabel tidak cukup — kalian butuh membatasi per baris atau per kolom.

• Column-level: user tidak boleh melihat kolom sensitif seperti email atau phone. MySQL mendukung ini lewat views atau kolom VIRTUAL yang disensor. Buat view yang hanya menampilkan kolom aman, lalu beri grant ke view itu saja.
• Row-level: user hanya boleh melihat baris milik dirinya sendiri. MySQL tidak punya row-level security bawaan, tapi bisa disimulasikan dengan view yang menyaring WHERE tenant_id = ... dan memaksa akses lewat view.

CREATE VIEW public_users AS
SELECT user_id, name FROM users

CREATE VIEW di atas menampilkan hanya kolom user_id dan name, menyembunyikan email dan data sensitif lain. Beri grant ke view ini untuk user reporting:

mysql -h 127.0.0.1 -P 15306 -e "GRANT SELECT ON commerce.public_users TO 'readonlyuser'@'%'"

Perintah mysql -h 127.0.0.1 -P 15306 mengeksekusi SQL via VTGate. Dengan pola view, kontrol akses bisa ditegakkan di level database, bukan hanya di aplikasi.

#Audit Logging dan Compliance

Audit menjawab pertanyaan: siapa melakukan apa, kapan, dan dari mana. Untuk compliance (seperti PCI-DSS atau data protection), jejak akses data sensitif biasanya wajib. Vitess menyediakan beberapa lapis audit:

• Query log VTGate — mencatat query yang melewati VTGate.
• Audit log MySQL — mencatat akses di level MySQL (perlu plugin audit).
• Access logs — dari component atau proxy di depan.

Mengaktifkan audit log MySQL lewat plugin audit_log di konfigurasi MySQL:

audit_log=ON
audit_log_file=/var/log/mysql/audit.log
audit_log_format=JSON

Baris audit_log=ON mengaktifkan plugin audit MySQL. Log JSON mencatat user, query, dan waktu — bahan dasar untuk investigasi dan compliance report.

Untuk memantau siapa yang sedang terhubung:

SELECT user, host, db, command FROM information_schema.processlist

Perintah SELECT ... FROM information_schema.processlist menampilkan sesi aktif — cara cepat melihat siapa yang sedang terhubung dan melakukan apa.

#Pemisahan Akses Aplikasi dan Admin

Prinsip penting: aplikasi dan admin tidak boleh memakai jalur yang sama. Pemisahan ini mencegah aplikasi yang ter-compromise mengakses alat admin, dan mencegah query aplikasi mengganggu operasi.

Pola pemisahan yang direkomendasikan:

• Aplikasi hanya terhubung ke VTGate dengan user aplikasi, tanpa DDL.
• Admin memakai vtctlclient ke vtctld, yang sebaiknya tidak terekspos publik dan hanya bisa diakses dari jaringan internal atau VPN.
• VTTablet dan vtctld memakai autentikasi mTLS antara komponen (episode 12).
• Readonly reporting memakai user terpisah dan idealnya diarahkan ke tablet RDONLY.

kubectl exec -it deploy/vtctld -- vtctlclient \
  -server localhost:15999 ListAllTablets

vtctlclient ListAllTablets dijalankan dari dalam Pod vtctld — akses admin tidak pernah keluar dari cluster, mengurangi permukaan serangan.

#Penutup

Pada episode 13 ini kalian sudah mengatur akses dan audit di Vitess: user dan privileges dengan prinsip least privilege, pembatasan akses kolom dan baris lewat views, audit logging untuk compliance, serta pemisahan jalur aplikasi, admin, dan reporting.

Inti yang harus dibawa pulang:

• Model akses Vitess berbasis user dan privileges MySQL.
• Pisahkan peran: appuser, ddluser, readonlyuser, dan admin dengan hak berbeda.
• Batasi akses kolom dengan views; waspadai biaya join lintas shard.
• Aktifkan audit log MySQL untuk kebutuhan compliance.
• Aplikasi hanya lewat VTGate, admin hanya lewat vtctld.
• Jangan pernah beri aplikasi hak DDL atau akses langsung ke tablet.

Di episode 14 berikutnya kita naik ke skala global: multi-region dan disaster recovery — geo-sharding, replikasi multi-region dan read locality, strategi DR, serta perencanaan global failover. Sampai jumpa!