Anda boleh melindungi laman WordPress tanpa pemalam keselamatan serba lengkap, tetapi membuang pemalam tidak menghapuskan kerja keselamatan. Kawalan perlu disediakan dengan sengaja melalui WordPress, platform hos, WAF atau proses operasi. Persediaan tanpa pemalam tidak semestinya lebih pantas atau selamat.

Panduan ini menerangkan lapisan kawalan praktikal dan batas keselamatan manual. Konfigurasi pelayan berbeza-beza. Buat sandaran, uji perubahan di luar persekitaran langsung dan minta hos atau pentadbir berkelayakan menyemak peraturan yang anda tidak fahami.

Perkara utama

  • Kemas kini WordPress, tema, pemalam, perisian pelayan dan kebergantungan.
  • Gunakan akaun individu, pengesahan kukuh dan akses minimum yang diperlukan.
  • Lindungi akaun hos, sandaran dan proses pemulihan, bukan papan pemuka WordPress sahaja.
  • Jangan salin peraturan pelayan atau arahan pangkalan data tanpa memahami kesan dan menguji cara untuk mengembalikannya.
  • Gunakan pemalam keselamatan jika ia menyediakan kawalan yang tidak dapat diurus pasukan dengan baik melalui cara lain.

Tentukan maksud “tanpa pemalam”

Pendekatan tanpa pemalam biasanya bermaksud tidak menggunakan produk keselamatan serba lengkap di dalam WordPress. Ia tidak bermaksud WordPress langsung tidak mempunyai pemalam atau tidak memerlukan pemantauan, kawalan kadar permintaan, siasatan malware dan tindak balas insiden. Sesetengah kawalan mungkin disediakan oleh hos terurus, WAF, alat identiti atau perkhidmatan pemantauan berasingan. Setiap satunya membawa kos dan tanggungjawab tersendiri.

Catat lapisan yang mengendalikan setiap kawalan. Jika tiada pihak bertanggungjawab, kawalan itu belum dilaksanakan hanya kerana pemalam telah dibuang.

Mulakan dengan akaun dan kemas kini

Gunakan versi WordPress, PHP, tema dan pemalam yang masih disokong. Buang komponen yang tidak digunakan dan dapatkan perisian daripada sumber dipercayai. Semak kemas kini, sediakan sandaran teruji dan pilih proses kemas kini yang sesuai dengan risiko laman. WordPress menyokong kemas kini automatik untuk tema dan pemalam, tetapi pasukan masih perlu memeriksa keserasian serta keadaan laman selepas perubahan.

Gunakan akaun individu untuk setiap orang, kata laluan kukuh dan unik serta pengesahan berbilang faktor jika tersedia. Utamakan perlindungan akaun hos, domain, e-mel dan pentadbir. Berikan akses minimum yang diperlukan bagi setiap tugas dan tarik balik akses dengan segera apabila peranan berubah atau kakitangan berhenti. Lindungi akaun e-mel pemulihan kerana ia boleh digunakan untuk menetapkan semula akses lain.

Lindungi hos, fail dan akses pangkalan data

Selamatkan panel kawalan hos dan hadkan akses shell, pangkalan data serta fail kepada pihak yang dibenarkan. Gunakan sambungan yang disulitkan untuk pentadbiran. Jangan simpan kelayakan production dalam repositori sumber atau mesej awam. Semak cara hos mengasingkan laman, mengemas kini perisian pelayan dan mengurus insiden.

Pemilikan serta kebenaran fail perlu membolehkan WordPress berfungsi sambil mengehadkan akses tulis yang tidak perlu. Nilai tepat bergantung pada persekitaran hos. Elakkan arahan pukal daripada tutorial lama. Minta hos mengesahkan tetapan yang sesuai untuk akaun dan model pelaksanaan anda.

Hadkan akses pangkalan data dan gunakan kelayakan berbeza. Jangan dedahkan perkhidmatan pentadbiran kepada umum. Jangan jalankan arahan pembersihan SQL daripada panduan sebelum mengesahkan nama jadual, tujuan dan sandaran. Perubahan pangkalan data yang salah boleh memadam kandungan atau merosakkan laman.

Gunakan kawalan rangkaian dan aplikasi berlapis

WAF, kawalan kadar permintaan dan pemantauan pada peringkat hos boleh membantu mengurus sebahagian trafik yang tidak diingini sebelum sampai ke WordPress. Ia tidak menghentikan semua serangan dan perlu dikonfigurasikan dengan teliti. Kekalkan akses untuk pengunjung, integrasi dan crawler yang sah. Uji peraturan dengan selamat dan pantau log untuk mengesan sekatan yang tersilap.

Nyahaktifkan ciri seperti XML-RPC hanya jika laman tidak bergantung padanya dan kaedah yang dipilih telah diuji. Menyembunyikan URL log masuk bukan pengganti pengesahan, kawalan akses atau pemantauan. Jangan guna arahan .htaccess Apache atau Nginx tanpa mengesahkan jenis pelayan, konfigurasi sedia ada dan pelan pemulihan.

Header keselamatan boleh mengurangkan risiko pelayar tertentu apabila ditetapkan dengan betul. Ia tidak membaiki kod aplikasi yang rentan atau menggantikan HTTPS. Tambah header berdasarkan keperluan laman dan uji borang, embed, API serta sumber lain selepas pelaksanaan.

Sandaran, pemantauan dan tindak balas insiden

Jika praktikal, simpan sandaran secara berasingan daripada akaun production. Tetapkan titik pemulihan dan tempoh pemulihan yang diperlukan perniagaan, tempoh salinan disimpan, pihak yang boleh mengaksesnya dan kekerapan ujian pemulihan. Sandaran yang tidak boleh dipulihkan bukan pelan pemulihan.

Pantau gangguan laman, perubahan fail yang tidak dijangka, aktiviti akaun mencurigakan dan notis keselamatan bagi perisian yang dipasang. Tentukan penerima amaran dan pihak yang menyiasat. Jika laman disyaki diceroboh, simpan bukti, hadkan akses terjejas, hubungi hos dan pegawai tindak balas yang berkelayakan, pulihkan sumber yang diketahui bersih, tukar kelayakan dan siasat laluan pencerobohan sebelum operasi biasa disambung.

Bila pemalam keselamatan sesuai digunakan

Pemalam khusus mungkin menyediakan papan pemuka, amaran, pengimbasan malware, perlindungan log masuk atau kawalan yang sukar diselaraskan dengan cara lain. Nilai ciri, penggunaan sumber, sejarah kemas kini, akses yang diperlukan dan pertindihannya dengan hos atau WAF. Elakkan memasang beberapa alat yang membuat perubahan bercanggah atau mengulangi kawalan tanpa pemilik yang jelas.

Matlamatnya ialah reka bentuk keselamatan yang boleh disokong. Jika pasukan tidak mampu menyelenggara kawalan manual, pemalam yang dijaga dengan baik atau perkhidmatan terurus mungkin mengurangkan jurang operasi. Catat tanggungjawab dan uji proses pemulihan laman.

Senarai semak pelaksanaan yang selamat

  1. Senaraikan laman, hos, domain, akaun, sambungan dan integrasi.
  2. Sahkan sandaran yang boleh dipulihkan dan cara mengembalikan perubahan.
  3. Kemas kini komponen yang disokong dan buang perisian yang tidak diperlukan.
  4. Hadkan akses pengguna, hos, pangkalan data dan fail mengikut peranan.
  5. Semak kawalan hos, WAF dan pemantauan bersama penyedia bertanggungjawab.
  6. Uji perubahan keselamatan pada staging dan periksa aliran laman biasa.
  7. Catat pemilik amaran, hubungan insiden dan langkah pemulihan.
  8. Semak semula reka bentuk apabila laman atau pendedahan risiko berubah.

Untuk kemas kini WordPress dan perancangan pemulihan berterusan, lihat perkhidmatan penyelenggaraan laman web. Panduan pengukuhan WordPress rasmi ialah rujukan berguna, tetapi tetapan khusus pelayan perlu dinilai mengikut konteks.

Soalan lazim

Adakah WordPress lebih selamat tanpa pemalam keselamatan?

Tidak secara automatik. Keselamatan bergantung pada kawalan yang disediakan dan cara ia diselenggara. Pemalam boleh menjadi sebahagian daripada reka bentuk yang baik, manakala persediaan manual boleh gagal jika tiada pihak memantau atau mengemas kininya.

Bolehkah saya tampal peraturan .htaccess daripada artikel keselamatan?

Jangan lakukannya tanpa mengesahkan pelayan menggunakan Apache, memahami setiap peraturan dan menguji cara pemulihan. Sesetengah peraturan boleh menyekat permintaan sah atau merosakkan ciri laman.

Adakah menukar URL log masuk menghentikan serangan?

Ia mungkin mengurangkan sesetengah permintaan automatik, tetapi tidak menggantikan pengesahan kukuh, akses minimum, pemantauan dan kemas kini.

Sumber dan nota semakan

Disemak pada 20 Oktober 2026. Panduan WordPress disemak berdasarkan panduan pengukuhan rasmi dan dokumentasi kemas kini pemalam serta tema. Keperluan keselamatan berbeza mengikut laman dan hos. Anggap pelaksanaan sebagai tanggungjawab operasi berterusan, bukan senarai semak sekali sahaja.