Lewati ke konten
CelestianDokumentasi Celestian

Keamanan

Halaman ini merangkum mekanisme keamanan yang dibangun ke dalam Celestian, sebagai bahan penilaian dan konfigurasi.

Autentikasi pengguna

Section titled “Autentikasi pengguna”
Aspek Mekanisme
Password Disimpan dengan argon2id (m = 19 MiB, t = 2, p = 1). Panjang minimum dapat dikonfigurasi dan dicek terhadap daftar password umum; tidak boleh memuat username atau bagian e-mail.
Sesi Access token JWT EdDSA berumur pendek (15 menit) dan refresh token opak yang dirotasi tiap pemakaian (7 hari). Hanya hash refresh token yang disimpan. Pemakaian ulang token lama di luar jendela 30 detik dianggap pencurian dan mencabut seluruh keluarga sesi.
Lockout Login gagal berulang (bawaan 10 kali dalam 15 menit) memblokir sementara per identifier dan per user, sehingga berganti e-mail atau username tidak menambah jatah percobaan. Admin workspace bisa membuka blokir dari UI.
Verifikasi e-mail Tautan bertoken yang kedaluwarsa. Verifikasi memakai tombol (POST) agar pemindai tautan e-mail tidak memakai token.
Reset password Mencabut semua sesi dan membuka blokir login. Permintaan lupa password dan kirim ulang verifikasi selalu dijawab sama (202) agar tidak membocorkan e-mail yang terdaftar.
Cookie sesi Terenkripsi (JWE), httpOnly, dan bertanda Secure di belakang HTTPS. Browser tidak pernah memanggil backend langsung.
Konsol admin Sesi terpisah (audience berbeda), cookie sameSite=strict terbatas pada /admin, dan kredensial berupa hash argon2id di konfigurasi server.

Kredensial perangkat

Section titled “Kredensial perangkat”
  • Device key disimpan sebagai hash argon2id dan hanya tampil sekali. Perangkat tersambung dengan username = ID device.
  • Broker memanggil backend (auth callout) pada setiap koneksi, publish, dan subscribe. Klien anonim ditolak. Hasil keputusan di-cache singkat.
  • Publisher yang tercatat pada pesan adalah identitas hasil autentikasi broker, bukan isi payload, sehingga tidak bisa dipalsukan.
  • Kebijakan client_id berawalan ID device di produksi mencegah satu kredensial dipakai dengan banyak identitas.
  • Bootstrap: protokol challenge-response (HMAC-SHA256) dengan respons terenkripsi AES-256-GCM, nonce sekali pakai, lockout per External ID, dan jawaban penolakan yang seragam.
  • Firmware diunduh lewat alamat bertanda tangan HMAC yang kedaluwarsa, dan keutuhan diverifikasi dengan SHA-256.

Otorisasi

Section titled “Otorisasi”
  • Deny by default dan deny mengalahkan allow.
  • Anti eskalasi hak: tidak bisa memberi izin yang tidak dimiliki sendiri; hak Admin hanya bisa diberikan oleh Admin; workspace selalu punya minimal satu Admin aktif.
  • Izin per objek dan per tag, direct policy, dan pewarisan lewat group.
  • 404 bagi non-anggota agar keberadaan workspace tidak bocor.
  • Setiap data selalu dibatasi ke workspace dari konteks akses, tidak pernah dari parameter klien.
  • Personal Access Token: hash SHA-256, terkunci ke satu workspace, hak efektif = irisan hak pemilik dan scope, tanpa aksi manajemen akses.

Perlindungan data

Section titled “Perlindungan data”
Aspek Mekanisme
Kredensial tersimpan Password PostgreSQL, token Telegram, header webhook, dan External Key Bootstrap dienkripsi AES-256-GCM dengan kunci server (SECRETS_KEY) dan terikat ke workspace. API tidak pernah mengembalikan nilainya.
Journal Semua mutasi dicatat dalam transaksi yang sama dengan snapshot sebelum dan sesudah. Rahasia tidak pernah masuk journal.
Ekspor CSV Nilai yang diawali =, +, -, atau @ dinetralkan (anti CSV injection).
Tautan publik dashboard Token acak 256 bit, hanya baca, data hanya lewat konfigurasi widget yang tersimpan, dibatasi laju, tidak diindeks, dan tanpa referrer. Pemberi akses harus sendiri boleh membaca semua channel yang dipakai.
Penghapusan Workspace dibekukan dengan masa tenggang sebelum dihapus permanen; pesan di TimescaleDB dibersihkan bertahap.

Eksekusi kode pengguna

Section titled “Eksekusi kode pengguna”
Komponen Pengamanan
Lua Interpreter baru per eksekusi, hanya pustaka base, table, string, math; tanpa os, io, package, debug, load*, require; timeout dan batas ukuran hasil.
Go Proses anak terpisah dengan validasi statis daftar putih paket, timeout, dan batas memori; di Linux ditambah seccomp, pembuangan capability, no_new_privs, dan batas sumber daya.
Template (e-mail, webhook, PostgreSQL, Bootstrap) text/template dibatasi (tanpa pemanggilan fungsi sembarang, rekursi, dan printf pada Bootstrap); template report divalidasi dengan daftar putih HTML (tanpa script, iframe, form, atribut on*).
Output jaringan PostgreSQL, Webhook, dan Telegram menolak alamat privat, lokal, link-local, dan CGNAT (diperiksa pada IP hasil resolusi, jadi DNS rebinding tidak lolos) kecuali administrator mengizinkan. Nama tabel dan kolom divalidasi dan nilai selalu parameter.

Jaringan dan MQTT

Section titled “Jaringan dan MQTT”
  • MQTT biasa tidak terenkripsi. Gunakan MQTTS atau jaringan privat untuk lalu lintas melewati internet (MQTTS dan NTP).
  • Batasi MQTTS_BIND dan pasang firewall dengan batas laju koneksi per IP.
  • NTP terbuka bisa disalahgunakan untuk amplifikasi: batasi allow chrony ke gateway.
  • Reverse proxy wajib meneruskan Host dan X-Forwarded-* dengan benar karena Server Actions mencocokkan Origin dengan Host.

Praktik yang disarankan

Section titled “Praktik yang disarankan”
  1. Matikan pendaftaran mandiri setelah akun pertama dibuat; undang anggota lewat Invitations.
  2. Cadangkan SECRETS_KEY di luar server.
  3. Pakai role dengan hak sesempit mungkin dan token API dengan scope minimum.
  4. Nonaktifkan Go (RULES_GO_WORKERS=0) bila tidak dipakai.
  5. Batasi akses ke /admin di reverse proxy.
  6. Rutin mencadangkan database dan menguji pemulihannya.