Melindungi data saat transit: TLS/SSL untuk HTTP dan transport layer, pembuatan dan perpanjangan sertifikat, konfigurasi bind dan publish address, firewall, serta network isolation di VPC dan security groups.

Episode 15 mengamankan siapa yang boleh masuk. Episode 16 mengamankan data itu sendiri saat melintasi jaringan. Tanpa enkripsi, semua yang dikirim — termasuk password dan API keys — bisa disadap di tengah jalan oleh siapa pun yang berada di jalur jaringan yang sama.
Elasticsearch punya dua jalur komunikasi yang harus diamankan: HTTP layer (interaksi client seperti curl, Kibana, aplikasi) dan transport layer (komunikasi antar-node di dalam cluster). Episode 16 membahas keduanya, pembuatan dan perpanjangan sertifikat, pengaturan bind/publish address, serta isolasi jaringan di level firewall dan cloud.
TLS (Transport Layer Security) melindungi data saat transit lewat enkripsi. Ia bekerja dengan sertifikat digital: server membuktikan identitasnya (autentikasi server), dan client dapat memverifikasi bahwa koneksi memang menuju server yang benar. Di Elasticsearch, ada tiga jenis sertifikat:
HTTP layer adalah gerbang client — Kibana, aplikasi, curl. Semuanya harus lewat HTTPS. Konfigurasi di elasticsearch.yml:
xpack.security.http.ssl.enabled: true
xpack.security.http.ssl.keystore.path: elastic-certificates.p12
xpack.security.http.ssl.keystore.password: change-meSetelah aktif, semua akses HTTP wajib https://:
curl -k -u elastic:password https://localhost:9200/_cluster/health-k menonaktifkan verifikasi sertifikat — hanya untuk uji cepat. Di aplikasi sungguhan, kalian harus memakai CA yang dipercaya client agar verifikasi tetap aktif.
Transport layer adalah jalur antar-node. Tanpa enkripsi di sini, node penyusup bisa bergabung dan mencuri data dari dalam. Konfigurasi di elasticsearch.yml:
xpack.security.transport.ssl.enabled: true
xpack.security.transport.ssl.verification_mode: certificate
xpack.security.transport.ssl.keystore.path: elastic-certificates.p12
xpack.security.transport.ssl.truststore.path: elastic-certificates.p12verification_mode: certificate memverifikasi bahwa node lawan memegang sertifikat yang ditandatangani CA yang dipercaya — tanpa harus mencocokkan hostname. Ini wajib untuk mencegah man-in-the-middle di antara node.
Important
Jangan pernah mengaktifkan HTTP TLS saja dan membiarkan transport tanpa TLS. Transport yang terbuka adalah pintu belakang: node tidak dikenal bisa menyamar dan membaca lalu lintas cluster. Keduanya wajib aktif bersama.
Cara termudah mengelola sertifikat adalah dengan elasticsearch-certutil, tool bawaan:
bin/elasticsearch-certutil ca
bin/elasticsearch-certutil cert --ca elastic-stack-ca.p12 --pemPerintah pertama membuat CA (elastic-stack-ca.p12); perintah kedua membuat sertifikat per node yang ditandatangani CA tersebut. Sertifikat di-install ke keystore node (berkas .p12), dan CA disebar ke semua node sebagai truststore.
Sertifikat punya masa berlaku (default 5 tahun). Perpanjangan harus direncanakan, bukan dilakukan saat sudah expire — cluster yang sertifikatnya kadaluarsa akan gagal berkomunikasi antar-node dan semua client terputus. Polanya:
elasticsearch-certutil.Jadwalkan pengingat jauh sebelum masa berlaku habis, dan simpan renewal runbook — perpanjangan yang panik adalah sumber downtime klasik.
Dua setting ini sering membingungkan tapi menentukan siapa yang bisa menjangkau node:
network.host — alamat yang di-bind oleh node untuk menerima koneksi. 0.0.0.0 berarti semua antarmuka; 127.0.0.1 berarti hanya localhost.network.publish_host — alamat yang dipublikasikan ke node lain untuk ditemui. Penting di cloud: bind ke IP internal, publish ke IP yang bisa dijangkau node lain.network.host: 0.0.0.0
network.publish_host: 10.0.1.5
discovery.seed_hosts: ["10.0.1.5:9300", "10.0.1.6:9300"]Jika publish_host salah, node lain tidak bisa menemukan node ini meski bind sudah benar — kesalahan klasik saat deploy ke cloud.
Enkripsi menutup penyadapan; isolasi jaringan menutup akses. Aturan firewall ideal untuk Elasticsearch:
| Port | Protokol | Boleh diakses oleh |
|---|---|---|
| 9200 | HTTP/HTTPS | Client aplikasi, Kibana, admin (via VPN) |
| 9300 | Transport (TLS) | Hanya node Elasticsearch lain |
| 5601 | HTTPS | User yang boleh akses Kibana |
Contoh dengan UFW di Ubuntu:
sudo ufw default deny incoming
sudo ufw allow from 10.0.1.0/24 to any port 9300
sudo ufw allow from 10.0.1.0/24 to any port 9200
sudo ufw allow from 10.0.2.10 to any port 5601Prinsip utamanya: deny by default. Di cloud, set security groups dengan prinsip sama — port 9200 hanya dibuka ke subnet aplikasi dan admin, port 9300 hanya antar-node, dan semua berada dalam VPC yang tidak terekspos internet.
Tip
Terapkan defense in depth: enkripsi + autentikasi + firewall + network isolation sekaligus. Enkripsi tidak melindungi dari port 9200 yang terbuka publik tanpa autentikasi; firewall tidak melindungi dari traffic yang sudah masuk jaringan. Gabungkan keduanya, dan jangan lupa gunakan reverse proxy dengan HTTPS untuk Kibana di production.
Sertifikat self-signed tanpa truststore. Client gagal verifikasi — instal CA ke truststore client.
Sertifikat expire tanpa perencanaan. Cluster mendadak mati komunikasi — jadwalkan perpanjangan dan renewal drill.
Transport TLS dimatikan. Membuka pintu belakang cluster — selalu aktifkan keduanya.
publish_host salah di cloud. Node tidak bisa ditemukan — cek IP yang benar-benar bisa dijangkau peer.
Port 9200 terbuka ke internet. Menunggu serangan — deny by default dan hanya buka yang perlu.
Di episode 16 kalian menguasai network security dan encryption: TLS untuk HTTP dan transport layer, pembuatan CA dan sertifikat dengan elasticsearch-certutil, strategi perpanjangan sertifikat dengan rolling restart, bind vs publish host, serta firewall dan network isolation di level port dan VPC.
Inti yang harus dibawa pulang:
elasticsearch-certutil dan di-perpanjang sebelum expire.network.host untuk bind; network.publish_host untuk ditemui node lain.Sekarang akses sudah aman. Tapi keamanan juga berarti bisa membuktikan siapa yang mengakses apa. Di episode 17 kita bahas audit logging dan compliance: mengaktifkan audit log, tipe event, format output file dan index, filtering event, serta pertimbangan GDPR, kebijakan retensi data, dan penanganan data pribadi. Sampai jumpa!