Keamanan Siber

Keamanan siber jarang menjadi berita baik. Ia terasa paling nyata justru saat sudah terlambat: data pelanggan bocor, transfer dikirim ke rekening yang salah, atau situs tidak bisa dibuka saat jam sibuk. Topik ini mengumpulkan cara kami memandang keamanan di tbskit — ancaman yang paling sering berhasil, lapisan pertahanan yang kami pasang pada setiap proyek, dan kebiasaan kecil yang paling banyak mengurangi risiko.

Mengapa ini soal kebiasaan, bukan hanya teknologi

Sebagian besar insiden yang menimpa situs kecil dan menengah tidak dimulai dari kerentanan yang belum pernah ada di dunia. Ia dimulai dari hal yang sudah diketahui dan belum ditutup: akun lama yang masih aktif, kata sandi yang dipakai ulang, perangkat yang menunggu pembaruan sejak berbulan lama, atau permintaan mendesak yang dipenuhi tanpa verifikasi.

Itu sebabnya keamanan kami perlakukan sebagai rutinitas, bukan proyek. Sebuah proyek keamanan selesai dan dilupakan; sebuah rutinitas berjalan terus dan tetap murah: menambal, memeriksa, mencabut akses yang tidak lagi dipakai, dan mengulang hal itu tanpa menunggu insiden.

Model ancaman yang kami pakai

Kami tidak memulai dari daftar alat, tetapi dari tiga pertanyaan singkat yang dijawab bersama pemilik proyek:

• Apa yang layak diambil? Data pelanggan, akses ke sistem pembayaran, akses ke repositori dan hosting, atau reputasi merek. Setiap hal yang layak diambil butuh perlakuan berbeda.
• Siapa yang mungkin tertarik? Penipu yang mengejar uang, pengirim spam, pesaing, orang dalam yang keluar dari proyek, atau bot yang memindai seluruh internet tanpa menyasar siapa pun secara khusus.
• Bagaimana jalur masuknya? Email dan pesan, formulir dan unggahan berkas, akun dengan hak istimewa, layanan pihak ketiga, serta perangkat kerja sehari-hari.

Jawabannya menentukan urutan pekerjaan. Proyek yang menyimpan data pembayaran mendapat prioritas berbeda dari situs profil perusahaan — tetapi keduanya tetap mendapat versi terkecil dari daftar yang sama.

Lapisan pertahanan yang kami pasang

Tidak ada satu alat yang cukup, jadi kami menyusun pertahanan berlapis dan menganggap setiap lapisan bisa gagal.

Identitas dan akses

• Setiap orang memakai akun sendiri. Akun bersama menghapus jejak siapa melakukan apa dan membuat proses keluar dari proyek tidak terkendali.
• Two-factor di semua akun penting — DNS, hosting, repositori, email, dan layanan media — karena akun-akun itulah yang bisa menjatuhkan situs sekaligus membocorkannya.
• Hak paling minimal sesuai peran, ditinjau setiap triwulan, termasuk pencabutan akses saat seseorang berhenti terlibat.

Aplikasi dan kode

• Validasi input di sisi server, karena validasi di browser adalah kenyamanan, bukan pengamanan.
• Kueri berparameter untuk semua akses basis data, sehingga input pengguna tidak pernah menjadi bagian dari perintah yang dieksekusi.
• Encoding keluaran dan Content Security Policy agar kode pihak lain tidak bisa berjalan di halaman pengunjung.
• Dependensi dijaga sedikit dan diperbarui. Setiap paket adalah kontrak perawatan yang tidak pernah kedaluwarsa — perhatikan standar kode kami.

Infrastruktur dan jaringan

• HTTPS di semua tempat, dengan TLS dikelola dan diperbarui otomatis.
• Header keamanan (HSTS, X-Content-Type-Options, Referrer-Policy, dan CSP) diatur di tingkat host, bukan diserahkan ke ingatan setiap kali menambah halaman.
• Permukaan yang tidak dipakai dihapus, termasuk DNS record lama, subdomain uji, dan endpoint yang tidak lagi dipakai.
• Backup terpisah dan diuji pulih. Backup yang belum pernah dipulihkan baru berupa harapan — lihat cara kami menyimpan dan melayani situs.

Manusia dan proses

• Verifikasi permintaan sensitif lewat kanal lain. Permintaan transfer atau perubahan akses tidak pernah dipenuhi hanya berdasarkan satu email.
• Pelatihan singkat dan berkala, dengan contoh nyata yang beredar di wilayah pengguna, bukan kuis teori.
• Runbook untuk hari buruk. Apa yang diperiksa lebih dulu, siapa yang diberi tahu, dan bagaimana mengembalikan keadaan — bagian dari kebiasaan ops kami.

Kebiasaan yang paling banyak mengurangi risiko

Kalau hanya ada waktu untuk lima hal, urutannya biasanya seperti ini:

1. Autentikasi multifaktor di email, DNS, hosting, dan repositori.
2. Kata sandi panjang dan unik untuk setiap akun, dikelola dengan password manager.
3. Pembaruan rutin untuk sistem operasi, aplikasi, plugin, dan dependensi.
4. Backup terpisah yang bisa dipulihkan, beserta jadwal uji pemulihannya.
5. Verifikasi permintaan sensitif melalui kanal di luar pesan yang meminta.

Sisanya adalah perbaikan bertahap: kontrol akses yang dirapikan, pemantauan yang dinyalakan, notifikasi yang dipastikan sampai ke manusia, dan dokumentasi yang tetap benar setelah orang yang membuatnya pindah tugas.

Yang tidak kami janjikan

Keamanan sempurna tidak ada, dan menawarkannya justru menyesatkan. Yang kami janjikan lebih sederhana: risiko yang terukur, keputusan yang bisa dijelaskan, dan kesalahan yang tidak dihukum — karena tim yang takut melaporkan masalah lebih berbahaya daripada masalah itu sendiri.

Apa yang kami terbitkan di topik Keamanan Siber

Artikel di topik ini masuk ke detail praktis: mengenali pola serangan yang paling umum, mengamankan akun dan akses, merapikan pertahanan aplikasi, menyiapkan backup yang benar-benar bisa dipulihkan, serta kebiasaan menanggapi insiden tanpa panik. Mulainya dari peta ancaman: 15 jenis serangan siber yang perlu diketahui merangkum pola yang paling sering ditemui beserta langkah pencegahannya.

Bacaan terkait: standar kode kami, kebiasaan ops yang menjaga keadaan tetap, dan panduan praktis yang kami rawat.

Ingin memeriksa kesiapan keamanan situs atau infrastruktur Anda? Ceritakan lingkungan Anda dan kami mulai dari daftar terpendek yang paling banyak mengurangi risiko.