Keamanan n8n: Kredensial, Akses User, dan Audit

n8n menyimpan kunci ke hampir semua aplikasi bisnis Anda: akun Google, database penjualan, software akuntansi, API pembayaran. Kalau instance n8n dibobol, penyerang bukan hanya melihat workflow, tapi bisa memakai semua akses itu. Jadi keamanan n8n perlu dijaga di beberapa lapis sekaligus: server, pintu masuk, akun user, kredensial, dan catatan aktivitas.

Artikel ini fokus ke n8n self-hosted, karena di situ tanggung jawab keamanan ada di tangan Anda. Kalau Anda memakai n8n Cloud, sebagian besar urusan server dan update sudah diurus n8n, tapi pengaturan user dan kredensial tetap tugas Anda.

Lapisan keamanan n8n

Bayangkan keamanan n8n seperti tumpukan lapisan. Setiap lapisan menahan jenis serangan yang berbeda. Kalau satu lapisan jebol, lapisan berikutnya masih menahan.

1. Jaringan: hanya port yang perlu yang terbuka, server tidak bisa diakses sembarangan.
2. Reverse proxy: semua akses lewat HTTPS, dengan sertifikat SSL yang valid.
3. Autentikasi: setiap orang punya akun sendiri, dengan two-factor authentication (2FA).
4. Kredensial terenkripsi: password dan token aplikasi tersimpan terenkripsi di database.
5. Audit dan log: Anda tahu siapa melakukan apa, dan ada pemeriksaan rutin.

Kalau Anda memasang n8n dengan Docker seperti di panduan cara install n8n dengan Docker, lapisan jaringan dan reverse proxy biasanya sudah ikut disiapkan. Bagian berikut membahas lapisan lainnya.

Enkripsi dan penyimpanan kredensial

Setiap kali Anda menambahkan kredensial (misalnya akun Gmail atau API key), n8n menyimpannya terenkripsi di database. Kunci enkripsinya diatur lewat variabel lingkungan N8N_ENCRYPTION_KEY. Kalau tidak diisi, n8n membuat kunci acak saat pertama kali jalan dan menyimpannya di folder data n8n.

Beberapa hal yang wajib diperhatikan:

• Tetapkan kunci enkripsi sendiri dan simpan di tempat aman, misalnya password manager tim. Kalau kunci ini hilang, kredensial di database tidak bisa dibuka lagi, termasuk saat Anda memulihkan backup.
• Jangan simpan kunci di repository yang sama dengan file konfigurasi publik.
• Pisahkan kredensial per kebutuhan. Satu akun Google untuk laporan, satu lagi untuk arsip dokumen. Kalau satu bocor, dampaknya terbatas.
• Beri hak akses minimum. Kredensial database untuk laporan cukup punya akses baca. Token API cukup punya izin yang dipakai workflow.
• Hapus kredensial yang tidak dipakai. Fitur audit n8n (dibahas di bawah) bisa menunjukkan kredensial yang tidak dipakai di workflow mana pun.
• Hindari menulis password langsung di node, misalnya di Code node atau di URL HTTP Request. Selalu pakai fitur kredensial.

Untuk paket berbayar, n8n juga mendukung external secrets, yaitu mengambil kredensial dari penyimpanan rahasia terpisah seperti vault. Untuk tim kecil, kredensial bawaan yang terenkripsi dengan kunci yang dijaga baik biasanya sudah cukup.

Akses user dan pembagian project

Jangan pakai satu akun owner bersama untuk seluruh tim. Buat akun terpisah untuk setiap orang, supaya aktivitas bisa dilacak dan akses bisa dicabut saat ada karyawan keluar.

Pengaturan yang disarankan:

• Aktifkan 2FA untuk semua user. Admin bisa mewajibkan 2FA untuk seluruh instance.
• Batasi jumlah admin. Cukup satu owner dan satu cadangan.
• Cabut akses di hari terakhir karyawan, sama seperti email kantor.

Soal pembagian akses yang lebih rinci, perlu dicatat: fitur Projects, berbagi workflow dan kredensial antar user, SSO (SAML, LDAP), serta log streaming termasuk fitur berbayar di n8n. Di Community Edition gratis, pilihan pembagian aksesnya lebih terbatas. Kalau tim Anda besar dan butuh akses bertingkat per divisi, pertimbangkan paket berbayar atau pisahkan instance. Detail paket bisa berubah, jadi cek halaman harga resmi n8n. Perbandingan versi cloud dan self-hosted kami bahas di artikel n8n self hosted vs cloud.

Mengamankan webhook publik

Webhook adalah URL yang bisa dipanggil dari luar untuk menjalankan workflow. Karena terbuka ke internet, webhook adalah pintu yang paling sering dicoba orang iseng.

Node Webhook di n8n menyediakan beberapa pengaman:

• Autentikasi: Basic auth, Header auth (misalnya token rahasia di header), atau JWT auth.
• IP allowlist: hanya alamat IP tertentu yang boleh memanggil. Request dari IP lain ditolak.
• Validasi isi: setelah webhook, tambahkan pengecekan bahwa data yang masuk sesuai format yang diharapkan sebelum diproses.

Selain itu:

• Jangan pakai webhook tanpa autentikasi untuk workflow yang menulis data, mengirim uang, atau mengirim pesan ke pelanggan.
• Kalau pengirimnya layanan pihak ketiga (misalnya payment gateway), cek tanda tangan atau token yang mereka kirim.
• Nonaktifkan workflow webhook yang sudah tidak dipakai.

Update versi dan patch

Ini lapisan yang paling sering diabaikan. Antara akhir 2025 dan awal 2026, beberapa celah keamanan kritis ditemukan di n8n. Salah satunya CVE-2026-21858 dengan skor CVSS 10.0, yang memungkinkan penyerang tanpa login mengambil alih instance lewat webhook tertentu. n8n Cloud langsung ditambal oleh tim n8n, sementara instance self-hosted baru aman setelah pemiliknya melakukan update.

Kebiasaan yang perlu dibangun:

1. Pantau rilis dan pengumuman keamanan n8n, misalnya lewat halaman release notes dan GitHub security advisories.
2. Jadwalkan update rutin, misalnya dua minggu sekali, dan segera untuk patch keamanan.
3. Backup dulu sebelum update: database, folder data, dan kunci enkripsi.
4. Tes di instance staging kalau workflow Anda banyak dan kritis.
5. Jangan buka editor n8n ke internet kalau tidak perlu. Batasi akses editor lewat VPN atau IP kantor, dan biarkan hanya jalur webhook yang publik.

Pengaman lain yang bisa diaktifkan lewat variabel lingkungan:

• N8N_PUBLIC_API_DISABLED=true kalau Anda tidak memakai public API n8n.
• NODES_EXCLUDE untuk memblokir node yang berisiko, seperti node yang bisa menjalankan perintah di server. Di versi terbaru, beberapa node berisiko sudah diblokir secara default.
• N8N_BLOCK_ENV_ACCESS_IN_NODE=true supaya workflow tidak bisa membaca variabel lingkungan server.

Checklist audit keamanan

n8n punya fitur security audit bawaan. Anda bisa menjalankannya lewat perintah n8n audit, lewat public API, atau lewat node n8n di dalam workflow. Laporannya mencakup lima area: kredensial yang tidak dipakai, query database yang memakai expression, node yang mengakses file system, node berisiko termasuk community node, serta pengaturan instance seperti webhook yang tidak terlindungi dan versi yang sudah usang.

Jalankan audit ini rutin, misalnya sebulan sekali, lalu lengkapi dengan checklist berikut:

• Kunci enkripsi tersimpan aman dan ikut dalam prosedur backup.
• Semua user punya akun sendiri dan 2FA aktif.
• Akun karyawan yang sudah keluar sudah dinonaktifkan.
• Tidak ada kredensial yang tidak dipakai.
• Semua webhook yang menulis data memakai autentikasi.
• Versi n8n tidak tertinggal lebih dari satu atau dua rilis minor.
• Editor n8n tidak terbuka bebas ke internet.
• Backup workflow berjalan dan pernah dites pemulihannya.
• Ada notifikasi saat workflow gagal atau berperilaku aneh.

Untuk dua poin terakhir, Anda bisa memakai workflow backup ke GitHub dan pemantauan eksekusi.

Kalau Anda menjalankan n8n sendiri dan belum yakin pengaturannya sudah aman, Aqilatic bisa membantu meninjau instance dan workflow Anda lewat audit proses gratis. Kami juga bisa merawat instance n8n untuk tim yang tidak punya orang IT, detailnya di layanan kami.

Pertanyaan yang sering muncul

Apakah kredensial di n8n aman?

Kredensial disimpan terenkripsi di database. Keamanannya bergantung pada kunci enkripsi yang dijaga baik, akses server yang terbatas, dan versi n8n yang selalu diperbarui.

Apakah n8n Cloud lebih aman daripada self-hosted?

Untuk urusan server dan patch, n8n Cloud lebih praktis karena diurus n8n. Self-hosted bisa sama aman, asalkan ada orang yang rutin update, backup, dan memantau.

Apa yang terjadi kalau kunci enkripsi hilang?

Kredensial yang tersimpan tidak bisa dibuka lagi. Workflow tetap ada, tapi semua kredensial harus dibuat ulang satu per satu. Karena itu kunci enkripsi harus ikut disimpan di prosedur backup.