Keamanan: vhost, Permission, TLS, dan Pengerasan

Hal Pertama: Hapus User `guest`

Setiap instalasi RabbitMQ hadir dengan user guest berpassword guest. Secara bawaan ia hanya bisa dipakai dari localhost, tetapi banyak orang melonggarkan itu tanpa menyadari konsekuensinya.

langkah pertama produksibash

rabbitmqctl add_user admin "$(openssl rand -base64 32)"
rabbitmqctl set_user_tags admin administrator
rabbitmqctl set_permissions -p / admin ".*" ".*" ".*"

rabbitmqctl delete_user guest       # hapus, bukan sekadar ganti password

⛔ loopback_users = none membuka guest ke seluruh jaringan

Setelan ini sering muncul di contoh Docker agar memudahkan pengujian. Di produksi, ia berarti siapa pun yang bisa menjangkau port 5672 dapat masuk dengan guest/guest dan membaca seluruh pesan Anda.

Bila Anda memang perlu setelan itu untuk user lain, hapus guest lebih dulu.

Vhost: Isolasi Sungguhan

pemisahan per timbash

rabbitmqctl add_vhost pembayaran
rabbitmqctl add_vhost notifikasi

rabbitmqctl add_user svc-pembayaran "$(openssl rand -base64 24)"
rabbitmqctl set_permissions -p pembayaran svc-pembayaran ".*" ".*" ".*"
# user ini TIDAK punya akses apa pun ke vhost notifikasi

Vhost memisahkan exchange, queue, binding, dan izin secara total. Dua tim bisa memakai nama queue yang sama tanpa saling mengganggu, dan kebocoran kredensial satu tim tidak membuka data tim lain.

Model Izin: Tiga Pola Regex

anatomi izinbash

rabbitmqctl set_permissions -p <vhost> <user> \
    "<configure>" "<write>" "<read>"

Izin	Mengizinkan
configure	Membuat/menghapus queue dan exchange
write	Publish ke exchange, membuat binding (sisi sumber)
read	Consume dari queue, membuat binding (sisi tujuan)

izin berprinsip least privilegebash

# producer: hanya boleh publish ke exchange pesanan, tidak boleh membuat apa pun
rabbitmqctl set_permissions -p / svc-pesanan-producer \
    "^$" \
    "^pesanan$" \
    "^$"

# consumer: hanya boleh membaca queue miliknya
rabbitmqctl set_permissions -p / svc-email-consumer \
    "^pesanan\.email$" \
    "^pesanan\.(dlx|email)$" \
    "^pesanan\.email$"

# monitoring: hanya membaca metrik, tidak menyentuh pesan
rabbitmqctl add_user monitoring "$(openssl rand -base64 24)"
rabbitmqctl set_user_tags monitoring monitoring
rabbitmqctl set_permissions -p / monitoring "^$" "^$" "^$"

rabbitmqctl list_permissions -p /

⚠️ ".*" untuk setiap aplikasi adalah kelalaian yang umum

Memberi ".*" ".*" ".*" kepada semua layanan berarti satu kredensial yang bocor membuka seluruh sistem pesan: pembacaan semua queue, penghapusan queue orang lain, dan publish palsu ke exchange mana pun.

Menyusun pola izin memakan waktu sekitar sepuluh menit per layanan, dan membatasi kerusakan secara drastis.

User Tag

Tag	Akses
(tanpa tag)	Hanya AMQP, tidak bisa membuka UI
`management`	UI untuk vhost yang diizinkan saja
`monitoring`	UI dan seluruh metrik, semua vhost
`policymaker`	Mengelola policy dan parameter
`administrator`	Semuanya, termasuk user dan vhost

Aplikasi seharusnya tanpa tag — ia hanya butuh AMQP. Memberi tag administrator kepada service account adalah kesalahan yang sering ditemukan saat audit.

TLS

rabbitmq.conf — TLSini

listeners.tcp   = none            # matikan port tanpa enkripsi
listeners.ssl.default = 5671

ssl_options.cacertfile = /etc/rabbitmq/certs/ca.pem
ssl_options.certfile   = /etc/rabbitmq/certs/server.pem
ssl_options.keyfile    = /etc/rabbitmq/certs/server-key.pem
ssl_options.verify     = verify_peer
ssl_options.fail_if_no_peer_cert = false
ssl_options.versions.1 = tlsv1.3
ssl_options.versions.2 = tlsv1.2

management.ssl.port     = 15671
management.ssl.cacertfile = /etc/rabbitmq/certs/ca.pem
management.ssl.certfile   = /etc/rabbitmq/certs/server.pem
management.ssl.keyfile    = /etc/rabbitmq/certs/server-key.pem

klien TLSjavascript

const koneksi = await amqp.connect({
  protocol: 'amqps',
  hostname: 'rabbit.internal',
  port: 5671,
  username: process.env.RMQ_USER,
  password: process.env.RMQ_PASS,
  heartbeat: 60
}, {
  ca: [fs.readFileSync('/etc/ssl/certs/ca.pem')],
  servername: 'rabbit.internal'          // verifikasi hostname
});

💡 TLS antar node cluster berbeda dari TLS klien

Komunikasi antar node memakai distribusi Erlang di port 25672, bukan AMQP. Mengaktifkan TLS untuk klien tidak mengenkripsi lalu lintas antar node.

Bila node tersebar antar AZ atau melewati jaringan yang tidak sepenuhnya tepercaya, aktifkan juga inter-node TLS lewat advanced.config — atau tempatkan seluruh cluster di jaringan privat yang terkendali.

Autentikasi Berbasis Sertifikat

mTLSini

# plugin rabbitmq_auth_mechanism_ssl
auth_mechanisms.1 = EXTERNAL
auth_mechanisms.2 = PLAIN

ssl_cert_login_from = common_name
ssl_options.fail_if_no_peer_cert = true

Dengan ini, identitas klien diambil dari CN sertifikatnya — tidak ada password yang perlu didistribusikan atau dirotasi. Cocok untuk lingkungan yang sudah punya PKI internal.

Checklist Pengerasan

User guest dihapus.
Setiap aplikasi punya user sendiri, tanpa tag, dengan izin berpola sempit.
Port 5672 tidak terekspos ke internet; hanya 5671 dengan TLS bila perlu diakses dari luar.
UI manajemen (15672) hanya dapat dijangkau dari jaringan internal atau lewat VPN.
Password dihasilkan acak dan disimpan di brankas rahasia, bukan di variabel lingkungan yang terlihat pada docker inspect.
loopback_users tidak dilonggarkan tanpa alasan yang jelas.
Erlang cookie acak dan berbeda per lingkungan.
Rotasi kredensial terjadwal, dan prosedurnya sudah pernah diuji.
Audit berkala dengan list_users, list_permissions, dan list_user_permissions.