Checklist Keamanan Website Pesantren yang Bisa Dikerjakan Pengurus

Gembok HTTPS tidak menjawab siapa yang masih bisa masuk sebagai administrator.

Website bisa memakai koneksi terenkripsi, sementara akun mantan petugas masih aktif atau arsip backup tersimpan di folder publik. Pemeriksaan keamanan perlu melihat beberapa lapisan sekaligus: akun, aplikasi, penyimpanan, dan kebiasaan kerja pengurus.

Checklist berikut adalah bahan pemeriksaan rutin dan pembagian tugas, bukan sertifikat keamanan. Pengurus perlu memastikan ada orang yang menangani setiap temuan; pekerjaan teknis yang belum dipahami diteruskan ke administrator, bukan dicoba langsung pada sistem produksi tanpa rencana.

Mulai dari akun yang bisa mengambil alih layanan #Tautan ke bagian Mulai dari akun yang bisa mengambil alih layanan

Catat administrator domain, hosting, DNS, email, dan aplikasi. Periksa apakah akun masih dipakai petugas yang tepat, kontak pemulihan dapat dijangkau lembaga, dan kata sandi tidak digunakan ulang untuk layanan lain.

Aktifkan MFA pada layanan yang mendukungnya dan lindungi kode pemulihan. Panduan CISA tentang MFA dapat dipakai sebagai bahan pengenalan bagi petugas. Jangan menganggap MFA membuat semua bentuk penipuan mustahil; petugas tetap tidak boleh membagikan kode atau menyetujui permintaan masuk yang tidak dimulainya.

Pada Pondok CMS, 2FA panel admin bersifat opsional dan memakai aplikasi autentikator. Portal wali belum mendukung 2FA. Karena itu, periksa pengaturan sesuai jenis akun, bukan menyatakan seluruh pengguna sudah dilindungi metode yang sama.

Periksa HTTPS tanpa menyamakan gembok dengan jaminan #Tautan ke bagian Periksa HTTPS tanpa menyamakan gembok dengan jaminan

Buka alamat resmi website dan pastikan memakai HTTPS tanpa peringatan sertifikat. Minta administrator memeriksa pengalihan HTTP, konfigurasi URL aplikasi, dan cookie sesi sesuai dokumentasi instalasi yang digunakan.

Jika memakai proxy seperti Cloudflare, pengaturan perlu disesuaikan dengan arsitektur sebenarnya. Jangan menyalin nilai konfigurasi dari website lain tanpa memahami jalur akses server. Dokumentasi HTTPS dan pemeriksaan Pondok CMS menjadi rujukan teknis untuk aplikasi ini.

HTTPS melindungi koneksi, tetapi tidak menentukan apakah seseorang berhak membaca dokumen. Tautan berkas pribadi yang terbuka untuk semua orang tetap bermasalah walaupun alamatnya dimulai dengan https://.

Uji hak akses dengan akun contoh yang diizinkan #Tautan ke bagian Uji hak akses dengan akun contoh yang diizinkan

Tinjau peran pengguna berdasarkan pekerjaan. Operator yang mengelola konten publik tidak otomatis membutuhkan hak membatalkan pembayaran atau mengubah seluruh pengaturan. Cabut akses yang tidak lagi diperlukan setelah perpindahan tugas.

OWASP Authorization Cheat Sheet membedakan autentikasi dari otorisasi: berhasil login tidak berarti boleh membuka seluruh sumber daya. Minta administrator menguji pembatasan menggunakan akun contoh dan lingkungan yang disetujui, bukan mencoba mengambil data pengguna nyata tanpa izin.

Periksa juga tautan unduhan, folder bersama, dan ekspor laporan. Dokumen yang diunduh ke komputer kantor membutuhkan perlindungan perangkat dan pembatasan pengguna, meskipun asalnya dari aplikasi dengan hak akses yang baik.

Tinjau pembaruan dan tempat penyimpanan #Tautan ke bagian Tinjau pembaruan dan tempat penyimpanan

Minta daftar versi aplikasi dan komponen yang menjadi tanggung jawab lembaga. Jadwalkan pembaruan dengan catatan perubahan, backup, serta cara kembali bila pembaruan bermasalah. Jangan menunda semua pembaruan sampai ada gangguan, tetapi jangan pula mengubah server saat penerimaan pembayaran sedang ramai tanpa koordinasi.

Pastikan rahasia seperti .env, arsip backup, dan salinan database tidak diletakkan di direktori publik. Pengurus cukup meminta bukti pemeriksaan dari administrator; tidak perlu mencoba membagikan tautan rahasia ke banyak orang untuk membuktikan berkasnya ada.

Gunakan checklist backup dan pemulihan untuk mengecek salinan di luar hosting serta latihan restore terpisah. Backup yang ada tetapi belum bisa dipulihkan meninggalkan risiko operasional yang belum selesai.

Latih cara menanggapi pesan mencurigakan #Tautan ke bagian Latih cara menanggapi pesan mencurigakan

Pesan yang meminta penggantian rekening, kode OTP, atau login mendesak perlu diperiksa melalui jalur lain yang sudah dikenal. Jangan memakai nomor kontak baru pada pesan itu sebagai satu-satunya cara verifikasi.

CISA menjelaskan tanda phishing, termasuk desakan emosional, permintaan informasi pribadi, dan alamat tautan yang meragukan. Pesan dengan bahasa rapi pun tetap bisa palsu. Ajarkan petugas membuka layanan dari alamat yang tersimpan, bukan mengikuti setiap tautan pada pesan masuk.

Tentukan tempat melapor tanpa menyalahkan pelapor. Jika petugas terlanjur memberikan akses, penanggung jawab perlu segera mengetahui akun dan waktu kejadian agar tindakan dapat dibatasi. Simpan bukti yang relevan secara aman; jangan menyebarkan ulang lampiran mencurigakan ke grup kerja.

Temuan jangan berhenti jadi catatan #Tautan ke bagian Temuan jangan berhenti jadi catatan

Untuk tiap pemeriksaan, catat hasil, bukti singkat, pemilik tindakan, dan tenggat. Bedakan “sudah diperiksa”, “belum diperiksa”, dan “perlu perbaikan”. Kotak yang belum terisi lebih jujur daripada tanda centang berdasarkan dugaan.

Ulangi peninjauan setelah pergantian operator, perubahan hosting, dan penambahan layanan. Gunakan panduan serah terima agar akses lama tidak tertinggal. Pengurus tidak perlu menguasai semua konfigurasi, tetapi perlu tahu siapa yang bertanggung jawab dan bukti apa yang menunjukkan pekerjaan benar-benar selesai.