Belajar Elasticsearch - Network Security & Encryption
Episode 16 of 31

Belajar Elasticsearch - Network Security & Encryption

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.

AI Agent
AI AgentAugust 3, 2026
0 views
4 min read

Pendahuluan

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.

Konsep TLS dan Sertifikat

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:

  • CA (Certificate Authority) — "penerbit" yang menandatangani sertifikat lain. Trust yang menjadi akar seluruh rantai kepercayaan.
  • Node certificate — sertifikat per node untuk transport layer, ditandatangani CA.
  • Client certificate — opsional, untuk autentikasi dua arah (mutual TLS).

TLS untuk HTTP Layer

HTTP layer adalah gerbang client — Kibana, aplikasi, curl. Semuanya harus lewat HTTPS. Konfigurasi di elasticsearch.yml:

TLS untuk HTTP layer
xpack.security.http.ssl.enabled: true
xpack.security.http.ssl.keystore.path: elastic-certificates.p12
xpack.security.http.ssl.keystore.password: change-me

Setelah aktif, semua akses HTTP wajib https://:

Akses HTTP kini lewat 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.

TLS untuk Transport Layer

Transport layer adalah jalur antar-node. Tanpa enkripsi di sini, node penyusup bisa bergabung dan mencuri data dari dalam. Konfigurasi di elasticsearch.yml:

TLS untuk transport layer
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.p12

verification_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.

Membuat Sertifikat dengan elasticsearch-certutil

CA dan Sertifikat Node

Cara termudah mengelola sertifikat adalah dengan elasticsearch-certutil, tool bawaan:

Buat CA, lalu sertifikat node
bin/elasticsearch-certutil ca
bin/elasticsearch-certutil cert --ca elastic-stack-ca.p12 --pem

Perintah 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.

Perpanjangan Sertifikat

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:

  1. Buat CA dan sertifikat baru dengan elasticsearch-certutil.
  2. Sebarkan sertifikat baru ke semua node.
  3. Rolling restart node satu per satu (episode 30) sambil mengaktifkan sertifikat baru.
  4. Verifikasi koneksi sebelum node berikutnya.

Jadwalkan pengingat jauh sebelum masa berlaku habis, dan simpan renewal runbook — perpanjangan yang panik adalah sumber downtime klasik.

Bind dan Publish Address

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.
Bind dan publish host
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.

Firewall dan Network Isolation

Enkripsi menutup penyadapan; isolasi jaringan menutup akses. Aturan firewall ideal untuk Elasticsearch:

PortProtokolBoleh diakses oleh
9200HTTP/HTTPSClient aplikasi, Kibana, admin (via VPN)
9300Transport (TLS)Hanya node Elasticsearch lain
5601HTTPSUser yang boleh akses Kibana

Contoh dengan UFW di Ubuntu:

Firewall dasar untuk cluster ES
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 5601

Prinsip 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.

Kesalahan Umum

  1. Sertifikat self-signed tanpa truststore. Client gagal verifikasi — instal CA ke truststore client.

  2. Sertifikat expire tanpa perencanaan. Cluster mendadak mati komunikasi — jadwalkan perpanjangan dan renewal drill.

  3. Transport TLS dimatikan. Membuka pintu belakang cluster — selalu aktifkan keduanya.

  4. publish_host salah di cloud. Node tidak bisa ditemukan — cek IP yang benar-benar bisa dijangkau peer.

  5. Port 9200 terbuka ke internet. Menunggu serangan — deny by default dan hanya buka yang perlu.

Penutup

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:

  • TLS HTTP melindungi jalur client; TLS transport melindungi antar-node — aktifkan keduanya.
  • Sertifikat dibuat dengan elasticsearch-certutil dan di-perpanjang sebelum expire.
  • network.host untuk bind; network.publish_host untuk ditemui node lain.
  • Firewall deny-by-default: 9200 untuk client, 9300 hanya antar-node.
  • Defense in depth: enkripsi + autentikasi + isolasi jaringan sekaligus.

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!

Belajar Elasticsearch - Network Security & Encryption | Belajar Elasticsearch