برای بالا بردن امنیت وردپرس، از سه کار شروع کن: مشخصکردن صاحبان دسترسی، داشتن بکآپ قابلبازیابی و رسیدگی به بهروزرسانیهای امنیتی. بعد سراغ هشدارها و برنامهٔ واکنش به مشکل برو. نصب یک افزونه بهتنهایی جای این کارها را نمیگیرد.
این راهنما برای صاحب سایت و مدیر وردپرسی نوشته شده که میخواهد بداند چه کاری را زودتر انجام بدهد و از کجا بفهمد درست انجام شده است. اگر هنوز با اجزای سایت آشنا نیستی، ابتدا راهنمای وردپرس چیست و چگونه کار میکند؟ را بخوان.
چکلیست اولویتدار امنیت وردپرس
امنیت وردپرس یعنی کاهش احتمال دسترسی غیرمجاز، تشخیص تغییرهای مشکوک و آمادگی برای بازیابی سایت؛ امنیت صددرصدی وعدهٔ واقعبینانهای نیست. راهنمای رسمی امنسازی وردپرس هم امنیت را کاهش ریسک تعریف میکند. Developer.WordPress.org
جدول زیر برنامهٔ پیشنهادی این مقاله است، نه زمانبندی اجباری برای همهٔ سایتها. اگر نشانهٔ نفوذ داری، مستقیم به بخش «اگر به هکشدن سایت شک کردیم» برو. آسیبپذیری شناختهشده و مهم هم نباید تا بررسی هفتگی منتظر بماند.
| اولویت | کار قابلانجام | از کجا بفهمیم انجام شده؟ |
|---|---|---|
| امروز | ثبت مالک و مسئول دامنه، هاست، ایمیل و وردپرس | ورود مالک و دسترسی به روش بازیابی هر حساب بررسی شده است. |
| امروز | بازبینی مدیران و دسترسی همکاران قبلی | هر حساب مدیریتی، صاحب مشخص و دلیل فعالبودن دارد. |
| امروز | رمزهای منحصربهفرد و ورود دومرحلهای | ورود تازه، عامل دوم میخواهد و روش بازیابی در دسترس است. |
| امروز، پیش از تغییر مهم | تهیهٔ بکآپ کامل و نگهداری نسخهای مستقل | فایلها و پایگاه داده در نسخهٔ پشتیبان وجود دارند و نسخهٔ مستقل قابلدسترسی است. |
| امروز | بررسی وصلهها و هشدارهای امنیتی | موارد مهم رفع شدهاند یا برای مهار فوری آنها مسئول مشخص شده است. |
| این هفته | حذف افزونهها و قالبهای واقعاً بیاستفاده | فهرست باقیمانده فقط شامل اجزای ضروری و وابستگیهای آنهاست. |
| این هفته | بررسی HTTPS | صفحات عمومی، ورود و پیشخوان بدون هشدار گواهی باز میشوند. |
| این هفته | آزمایش بازیابی | نسخهٔ پشتیبان در محیط جداگانه بالا آمده و بخشهای ضروری کار میکنند. |
| این هفته | تنظیم هشدار و مسئول رسیدگی | پیام آزمایشی به فرد مسئول رسیده است. |
| مستمر | ثبت نتیجهٔ بررسیها و تمرین بازیابی | آخرین تاریخ، نتیجه و کارهای باز مشخصاند. |
کنار هر ردیف، این چهار مورد را ثبت کن: مسئول، تاریخ بررسی، نتیجه و اقدام بعدی. کاری که نتیجهاش معلوم نیست، هنوز تأیید نشده است.
۱. اول مشخص کن کلیدهای سایت دست چه کسانی است
امنیت سایت فقط به رمز پیشخوان مربوط نیست. ایمیلی که لینک بازیابی رمز را دریافت میکند و حسابی که دامنه را کنترل میکند هم بخشی از همین زنجیرهاند.
برای سایتت یک فهرست خصوصی بساز:
| دارایی | چه چیزی ثبت شود؟ |
|---|---|
| دامنه و مدیریت DNS | مالک حساب، مسئول تمدید و راه بازیابی |
| هاست | صاحب حساب، راه تماس با پشتیبانی و افراد دارای دسترسی |
| ایمیل بازیابی | صاحب ایمیل و وضعیت ورود دومرحلهای |
| وردپرس | مدیران، مسئولیت هرکدام و دسترسیهای موقت |
| محل بکآپ | مسئول، محل نگهداری و روش دسترسی هنگام قطع سایت |
رمزها و کدهای بازیابی را داخل جدول مشترک یا پیام گروهی ننویس؛ برای رمزها از مدیر رمز عبور معتبر استفاده کن.
مثال فرضی: طراحی سایت تمام شده، اما حساب هاست و ایمیل بازیابی هنوز فقط در اختیار طراح قبلی است. در این وضعیت، تغییر رمز وردپرس مسئلهٔ مالکیت و بازیابی را حل نمیکند. ابتدا باید دسترسی مستقل صاحب کسبوکار برقرار شود.
اگر سایت در مرحلهٔ ساخت یا تحویل است، این فهرست را کنار خروجیهای ۹ مرحلهٔ اصلی ساخت وبسایت قرار بده تا تحویل سایت، شامل حسابها و مسئولیتها هم باشد.
هر همکار فقط بهاندازهٔ کارش دسترسی بگیرد
از «کاربران ← همهٔ کاربران» شروع کن. حسابهای مدیریتی را بررسی و برای هرکدام دلیل مشخصی پیدا کن.
طبق مستندات نقشهای کاربری وردپرس، نویسنده میتواند نوشتههای خودش را مدیریت و منتشر کند؛ ویرایشگر نوشتههای دیگران را هم مدیریت میکند. برای این کارها معمولاً دسترسی مدیرکل لازم نیست. افزونهها ممکن است نقشها و تواناییهای تازهای اضافه کنند، پس دسترسی واقعی را هم بررسی کن. WordPress.org
برای همکاران حساب جداگانه بساز و پس از پایان همکاری، دسترسیهایشان را لغو کن. پیش از حذف کاربر، وضعیت نوشتههای متعلق به او و انتقال آنها را مشخص کن.
معیار تأیید: حساب مدیریتی مشترک یا بیصاحب نداری؛ هر فرد با حساب خودش وارد میشود.
۲. ورود دومرحلهای را همراه با راه بازیابی فعال کن
ورود دومرحلهای یعنی ورود فقط به دانستن رمز وابسته نباشد؛ برای مثال، پس از رمز، کد برنامهٔ احراز هویت هم خواسته شود. در وردپرس خودمیزبان، روش فعالسازی به ابزار احراز هویت نصبشده بستگی دارد. راهنمای رسمی احراز هویت دومرحلهای وردپرس این لایهٔ حفاظتی را توضیح میدهد. Developer.WordPress.org
از حسابهای مدیر وردپرس و ایمیل بازیابی شروع کن؛ سپس در حساب هاست و دامنه، اگر ارائهدهنده پشتیبانی میکند، آن را فعال کن.
مراحل اجرایی:
- برای هر حساب حساس، رمز بلند و منحصربهفرد تعیین کن.
- ورود دومرحلهای را طبق راهنمای سرویس یا افزونه راهاندازی کن.
- کدهای بازیابی یا روش جایگزین را در محل امن نگه دار.
- بدون بستن نشست فعلی، در پنجرهٔ خصوصی مرورگر ورود تازه را امتحان کن.
معیار تأیید: ورود جدید عامل دوم میخواهد و میدانی اگر گوشی در دسترس نبود، چگونه حساب را بازیابی کنی.
۳. بکآپی داشته باش که واقعاً بتوانی برگردانی
طبق مستندات پشتیبانگیری وردپرس، بازیابی کامل یک سایت معمولی به فایلها و پایگاه داده نیاز دارد. فایلها شامل تصویرها، قالب و افزونهها هستند؛ نوشتهها و بسیاری از تنظیمات در پایگاه داده ذخیره میشوند. Developer.WordPress.org
حداقل یک نسخه را خارج از حساب هاست اصلی نگه دار و چند نقطهٔ زمانی داشته باش. دسترسی به بکآپ هم باید محدود باشد؛ این نسخه میتواند اطلاعات کاربران و تنظیمات حساس را در خود داشته باشد.
از میزبان بپرس: بکآپ شامل چه چیزهایی است، چند وقت نگه داشته میشود و بازیابی آن چگونه انجام میشود؟
فاصلهٔ بکآپ را با مقدار اطلاعات قابلازدسترفتن تعیین کن
این سؤال را جواب بده: «اگر مجبور شوم سایت را برگردانم، ازدسترفتن چند ساعت اطلاعات را میتوانم تحمل کنم؟»
مثال فرضی: سایتی هر روز درخواست مشاوره دریافت میکند. بکآپ شبانه ممکن است درخواستهای ثبتشده بعد از آخرین نسخه را پوشش ندهد. اگر ازدسترفتن این اطلاعات قابلقبول نیست، باید فاصلهٔ پشتیبانگیری کوتاهتر شود.
آزمون پیشنهادی برای تأیید بازیابی
از مسئول فنی بخواه یک نسخه را در محیط جداگانه و دارای محدودیت دسترسی بازیابی کند. در این محیط، پرداخت واقعی و ارسال پیام به مشتریان باید غیرفعال باشد.
بعد ورود، نمایش تصویرها، چند صفحهٔ مهم و عملکرد فرم ضروری را بررسی و تاریخ بکآپ، زمان صرفشده و نتیجه را ثبت کنید. بازشدن صفحهٔ اصلی بهتنهایی معیار کافی نیست.
۴. بهروزرسانی را با بکآپ و بررسی نتیجه انجام بده
بهروزرسانی هستهٔ وردپرس، قالب و افزونهها بخشی از رسیدگی امنیتی است. در راهنمای رسمی بهروزرسانی وردپرس نیز تهیهٔ نسخهٔ پشتیبان پیش از ارتقا توصیه شده است. Documentation
روال پیشنهادی:
- بخش «پیشخوان ← بهروزرسانیها» و اطلاعیهٔ سازنده را بررسی کن.
- از وجود بکآپ تازه و مسیر بازگشت مطمئن شو.
- تغییرهای حساس را، در صورت امکان، ابتدا در نسخهٔ آزمایشی بررسی کن.
- بهروزرسانی را اجرا کن.
- ورود، فرم تماس و مسیر اصلی استفاده از سایت را امتحان کن.
معیار تأیید: نسخهٔ جدید نصب شده و کار ضروری سایت بعد از تغییر همچنان انجام میشود.
اگر برای جزء نصبشده آسیبپذیری مهم اعلام شده، رسیدگی را عقب نینداز. وقتی وصله موجود نیست، مسئول فنی باید دربارهٔ غیرفعالسازی، جایگزینی یا محدودکردن دسترسی به آن تصمیم بگیرد.
بهروزرسانی خودکار خوب است، اگر پیگیری داشته باشد
وردپرس امکان فعالسازی بهروزرسانی خودکار را برای هر قالب یا افزونه فراهم میکند. مستندات بهروزرسانی خودکار دربارهٔ اعلان موفقیت یا شکست و احتمال اختلال در اجرای زمانبندی نیز توضیح میدهد. WordPress.org
اگر خودکارسازی فعال است، پیامهای نتیجه را بررسی کن. اگر خاموش است، مسئول و زمان مشخصی برای رسیدگی دستی داشته باش. برای افزونهای که عملکرد اصلی کسبوکار به آن وابسته است، برنامهٔ آزمون و بازگشت اهمیت بیشتری دارد.
۵. اجزای اضافی را حذف و اتصال امن را بررسی کن
قالب و افزونه را از مخزن رسمی یا سازندهٔ معتبر تهیه کن؛ این توصیه در راهنمای امنسازی وردپرس آمده است. نسخهای با منشأ نامعلوم را صرفاً بهخاطر فعالشدن قابلیت پولی، قابلاعتماد فرض نکن.
فهرست افزونهها و قالبها را مرور کن. موارد واقعاً بیاستفاده را پس از بررسی وابستگیها حذف کن؛ مثلاً قالب والدِ قالب فرزند ممکن است فعال نمایش داده نشود، اما همچنان ضروری باشد.
برای زیرساخت هم از میزبان بخواه وضعیت پشتیبانی امنیتی نسخهٔ PHP و نرمافزارهای سرور را بررسی کند. تغییر نسخه را با بررسی سازگاری سایت انجام بده.
HTTPS چه چیزی را تأمین میکند؟
HTTPS ارتباط مرورگر و سایت را رمزگذاری میکند؛ اما نشانهٔ نبود بدافزار در خود سایت نیست. راهنمای HTTPS وردپرس استفاده از اتصال امن را برای ورود مدیر و بازدیدکنندگان توصیه میکند. Developer.WordPress.org
معیار تأیید: صفحهٔ اصلی، ورود و پیشخوان با HTTPS و بدون هشدار گواهی باز میشوند. نسخهٔ HTTP هم باید به HTTPS هدایت شود. اگر تنظیمات SSL یا سرویس واسط داری، اصلاح مسیرها را با میزبان هماهنگ کن تا حلقهٔ تغییرمسیر ایجاد نشود.
۶. هشدارهایی تنظیم کن که کسی واقعاً آنها را بخواند
پیشنهاد اجرایی این مقاله این است که برای شروع، چهار رویداد را قابلپیگیری کنی:
- ایجاد مدیر جدید یا تغییر غیرمنتظرهٔ دسترسی؛
- شکست پشتیبانگیری؛
- شکست بهروزرسانی؛
- از دسترس خارجشدن سایت.
بسته به امکانات هاست و ابزارهای نصبشده، ثبت بعضی رویدادها به ابزار جداگانه نیاز دارد. برای هر هشدار، گیرنده و اقدام بعدی تعیین کن. «ایمیل ارسال شد» کافی نیست؛ باید معلوم باشد چه کسی رسیدگی میکند.
مثال فرضی: پیام شکست بکآپ به ایمیلی میرود که همکار سابق کنترل میکند. برنامه اجرا میشود، اما مسئول فعلی از مشکل خبر ندارد.
معیار تأیید: با قابلیت تست ابزار، یک پیام آزمایشی بفرست و دریافتش را بررسی کن. همچنین مطمئن شو یک رویداد مجاز آزمایشی در گزارش مربوط ثبت میشود.
برای شروع میتوانی بررسی کارهای باز را هفتگی و بازبینی دسترسیها را ماهانه انجام بدهی. این زمانبندی پیشنهادی است؛ هشدار مهم باید همان موقع بررسی شود.
اگر به هکشدن سایت شک کردیم، چه کنیم؟
مدیر ناشناس، انتقال بازدیدکننده به سایت نامرتبط یا هشدار بدافزار نیازمند بررسی فوریاند. کندی یا خطای سرور بهتنهایی اثبات نفوذ نیست.
بر پایهٔ راهنمای رسمی وردپرس برای سایت هکشده، این مسیر را دنبال کن: WordPress.org
- نشانهها را ثبت کن: آدرس صفحه، زمان مشاهده، تصویر خطا و تغییرهای اخیر.
- به میزبان و مسئول فنی اطلاع بده: اگر کاربران در معرض آسیباند، دسترسی عمومی را با هماهنگی محدود کنید.
- شواهد را حفظ کن: پیش از پاکسازی، نسخهای از وضعیت فعلی و گزارشها نگه دارید؛ آن را سالم فرض نکنید.
- دسترسیها را مهار کن: از دستگاه مطمئن رمزهای مرتبط را عوض و نشستها و دسترسیهای غیرمجاز را لغو کنید؛ پس از پاکسازی دوباره بازبینی کنید.
- علت را رفع و بازیابی را بررسی کن: برگرداندن بکآپ بدون بستن راه نفوذ ممکن است مشکل را تکرار کند.
بکآپ انتخابی باید از نظر آلودگی بررسی شود؛ قدیمیتر بودن، بهتنهایی سالمبودن را ثابت نمیکند.
پرسشهای متداول
آیا امنیت سایت کاملاً بر عهدهٔ شرکت هاست است؟
نه. میزبان معمولاً مسئول زیرساخت است، اما دامنهٔ خدمات هر قرارداد فرق دارد. مدیریت کاربران، اجزای نصبشده و پیگیری بازیابی باید مسئول مشخصی داشته باشد. از پشتیبانی بپرس دقیقاً چه مواردی را پوشش میدهد.
آیا با تغییر آدرس ورود وردپرس، سایت امن میشود؟
تغییر آدرس ورود، کنترل دسترسی به حساب را جایگزین نمیکند. اولویت را به رمز منحصربهفرد، عامل دوم، دسترسی محدود و رفع آسیبپذیری بده؛ مخفیکردن آدرس نباید مبنای اطمینان به امنیت باشد.
آیا سبز بودن «سلامت سایت» یعنی سایت هک نشده است؟
نه. این بخش برای بررسی وضعیت فنی و بعضی خطاها مفید است، اما گواهی پاکبودن سایت نیست. اگر نشانهٔ مشکوکی داری، همان نشانه باید جداگانه بررسی شود.
وقتی به پشتیبان دسترسی میدهم، چه نکتهای را رعایت کنم؟
حساب اختصاصی با دسترسی متناسب بساز و زمان پایان کار را مشخص کن. روش تحویل دسترسی باید امن باشد؛ پس از اتمام کار، حساب موقت و هر دسترسی مرتبط در هاست یا سرویسهای دیگر را بازبینی و لغو کن.
از اولین موردِ تأییدنشده شروع کن
لازم نیست همهٔ تنظیمات امنیتی را یکجا تغییر بدهی. امروز مشخص کن کنترل حسابها دست چه کسانی است، آخرین بکآپ قابلبازیابی کدام است و چه بهروزرسانی مهمی باقی مانده. برای هر موردِ باز، مسئول و اقدام بعدی بنویس.
برای بررسی نگهداری و امنیت سایتت با سبکتر، وضعیت دسترسی و پشتیبانگیری را توضیح بده: چه کسانی مدیرند، بکآپ کجا نگهداری میشود و آخرین آزمون بازیابی چه زمانی بوده است. برای شروع، نیازی به فرستادن رمزها نیست.
توی این مقاله
برای طراحی سایت، بهتر دیدهشدن یا تولید محتوا، از اینجا شروع کن.