چکلیست امنیت وردپرس از پایه؛ ۱۴ مورد قبل از انتشار
پیش از شروع، مرز با مقالهٔ همخوشهٔ خودمان روشن باشد: چکلیست ماهانهٔ امنیت وردپرس روتینِ بعد از انتشار است — کاری که هر ماه تکرار میشود تا سایت امن بماند. این مقاله یک پله قبلتر میایستد: چهارده موردی که باید پیش از روز اول انتشار قفل شوند، وقتی هنوز سایت در معرض نیست و هر تغییر، بدون هزینهٔ تعطیلی ممکن است. پایهٔ درست، روتینِ بعدی را کوچک و ارزان میکند؛ پایهٔ غلط، همان چکلیست ماهانه را به جیرهٔ آتشنشانی تبدیل میکند.
چرا این ترتیب مهم است؟ چون پایهٔ امنیتی بعداً بهسختی اصلاح میشود؛ جابهجایی هاستِ شتابزده یا افزودن گواهی به بستری که بدون آن طراحی شده، پروژهای جدا با ریسک تعطیلی میشود. به تجربهٔ ما اصلاحِ پایه پس از انتشار چند برابرِ همان کار در روز صفر هزینه دارد.
چرا امنیت وردپرس پیش از انتشار ساخته میشود؟
وردپرس حدود ۴۳ درصد از همهٔ وبسایتهای دنیا را پشتیبانی میکند (W3Techs، تاریخ گردآوری: آبان ۱۴۰۵). همین محبوبیت دو پیامد امنیتی دارد: اسکریپتهای حملهٔ خودکار بهطور پیشفرض وردپرس را هدف میگیرند، و هر حفرهٔ شناختهشده بلافاصله روی میلیونها سایت آزمون میشود. یعنی بخش بزرگی از ریسک با تصمیمهایی حذف میشود که فقط در روز صفر ارزاناند.
یک تصور غلط رایج را هم همین ابتدا برچینیم: «فعلاً سایت کوچک است، بعداً امن میکنیم.» حملهٔ خودکار سایز هدف را نمیبیند؛ رباتها فهرستوار از هزاران دامنه عبور میکنند و پایهٔ ضعیف، کوچکترین سایتها را هم در همان موج اول پیدا میکند.
به تجربهٔ ما سه دسته از نفوذهای رایج ریشه در پایه دارد، نه در روز حادثه: بستری که از اول بیپشتیبانی انتخاب شده، دسترسی مدیریتیِ پیشفرض، و نبود شبکهٔ بکاپ که بازگشت را ناممکن میکند. هر سه در روز صفر ارزانحلاند؛ بعد از انتشار، هر کدام پروژهای مستقل با ریسک تعطیلی میشوند. چکلیست این متن همین سه دسته را پوشش میدهد و یک لایهٔ پایش بالایش میگذارد.
چهارده مورد در چهار باند؛ نقشهٔ کل کار

چهارده مورد را در چهار باند مرتب میکنیم تا اجرایشان قابل زمانبندی باشد: بستر (چهار مورد)، هسته و فایلها (سه مورد)، دسترسی (چهار مورد) و بکاپ و پایش (سه مورد). این ترتیب اتفاقی نیست؛ هر باند پیشنیاز باند بعدی است — نمیشود روی بستری بیپشتیبان، دسترسی سختگیرانه ساخت و انتظار پایداری داشت. در سه سکشن بعد، هر باند را با جزئیات اجرا و زمان تقریبیاش باز میکنیم.
قاعدهٔ خواندن چکلیست هم روشن باشد: هر مورد یا «قفلشدنی» است یا «پایششدنی». قفلشدنیها یک بار در روز صفر انجام میشوند و دیگر به شما فکر نمیاندازند؛ پایششدنیها به روتین ماهانهٔ بعد از انتشار منتقل میشوند. از چهارده مورد این چکلیست، یازده مورد قفلشدنیاند و سه مورد — بکاپ، پایش لاگ و اسکن دورهای — لایهٔ پایشاند که در مقالهٔ ماهانهٔ همخوشه ادامه مییابند. اگر روز صفر را پنجرهای سهساعته ببینید، باند بستر و دسترسی حدود دو ساعتش را میگیرد و ساعت آخر به راهاندازی پایش میرسد.
لایهٔ بستر و هسته؛ هفت مورد پیش از نصب
باند اول بستر است و هفت مورد دارد. مورد یک، انتخاب هاست با سابقهٔ شفاف: پشتیبانی پاسخگو، ایزولهسازی حسابها و بکاپ سمت سرور؛ هاستِ ارزانِ بیسابقه گرانترین تصمیمِ این چکلیست است. مورد دو، نسخهٔ تازهٔ PHP و دیتابیس؛ نسخهٔ کهنه یعنی هم کندی و هم حفرهٔ شناختهشده. مورد سه، نصب گواهی امنیتی و ریدایرکت کامل به HTTPS از همان نصب، نه بعداً. مورد چهار، دانلود هستهٔ وردپرس فقط از منبع رسمی و نصب با آخرین نسخه.
مورد پنج، کلیدها و نمکهای امنیتی در فایل پیکربندی: مقدارهای پیشفرض یا خالی، درِ بازِ رمزنگاری کوکیهاست؛ کلیدساز رسمی وردپرس مقدار یکتا میسازد. مورد شش، مجوز فایلها و پوشهها طبق استاندارد توصیهشده — نه «۷۷۷ برای اینکه راحت باشد». مورد هفت، غیرفعالکردن ویرایشگر فایل داخل پیشخوان تا نفوذِ احتمالی به حساب مدیر مستقیماً به تغییر کد نرسد.
این هفت مورد را میشود در یک ساعت کاری روز صفر بست و سالها به آن فکر نکرد؛ به تجربهٔ ما همین باند بیشترین سهم را در کاهش حادثه دارد، چون بسترِ قفلشده در فیلترِ اول حملهٔ خودکار حذف میشود.
لایهٔ دسترسی؛ چهار مورد مدیر و ورود
باند دوم دسترسی است با چهار مورد. مورد هشت، نام کاربری مدیر یکتا: «admin» نه، نه در نام نمایشی و نه در نام کاربری؛ بروتفورس با همین پیشفرض شروع میکند. مورد نه، رمز بلند و یکتا که در مدیر رمز نگه داشته میشود — رمزهای تکراری بین سرویسها، امنیت سایت را به امنیت ضعیفترین سرویس شما گره میزند. مورد ده، ورود دومرحلهای برای همهٔ حسابهای مدیریتی؛ حتی رمز درزکرده با این لایه بیاثر میشود.
مورد یازده، سختسازی صفحهٔ ورود: محدودسازی تلاش ناموفق، تغییر نشانی ورود در صورت نیاز و قفل حساب پس از چند خطا. جزئیات اجرا با لایههای دفاعیاش در ایمنسازی صفحه ورود وردپرس با شش لایهٔ دفاعی آمده؛ نکتهٔ چکلیستی این است که باید پیش از انتشار فعال شود، وقتی هنوز کاربری به نشانی ورود عادت نکرده است.
یک تصمیم سازمانی هم اضافه کنید: مالکِ هر حساب از روز اول مشخص باشد. سایتهای چندنفره بعد از دو سه سال نمیدانند چه حسابهایی دارند؛ فهرست حسابها با نقش درست هر نفر، همان جایی است که جلوی «دسترسی یادمانده» را میگیرد.
لایهٔ بکاپ و پایش؛ سه مورد روز اول

باند سوم بکاپ و پایش است با سه مورد. مورد دوازده، شبکهٔ بکاپ از روز صفر: زمانبندی خودکار، نگهداری خارج از هاست و یک تست بازیابی واقعی قبل از انتشار؛ بکاپی که هیچوقت ریستور نشده، فرضیه است نه پشتیبان. روند کامل زمانبندی و تست بازیابی در بکاپ منظم وردپرس با روند قابلاتکا آمده؛ قاعدهٔ حداقلی: بکاپ روزانهٔ محتوا، هفتگیِ کامل، سی روز نگهداری.
مورد سیزده، ثبت فعالیت و پایش لاگ: افزونهٔ ثبت لاگین و تغییر محتوا از همان روز اول نصب شود، چون لاگِ روز اولِ خالی، تحقیق بعد از حادثه را کور میکند. مورد چهارده، اسکن بدافزار زمانبندیشده — نه درمان، آشکارساز زودهنگام. هر سه مورد ماهیت پایش دارند و ادامهشان به روتین ماهانه برمیگردد.
نکتهٔ اجرایی مهم این باند، محل نگهداری بکاپ است: بکاپی روی همان هاست، هم در سقوط هاست از بین میرود هم سطلی برای نفوذ میشود. نگهداری در مقصد جدا با رمز مستقل، همان تفکیکی است که بازیابیِ واقعی را ممکن میکند و به تجربهٔ ما تفاوتِ «تعطیلی یک روزه» با «شروع از صفر» را میسازد.
از پایه به روتین؛ مرزهای صادقانه و اتصال به چکلیست ماهانه
مرز صادقانهٔ این چکلیست را مکتوب بگوییم: چهارده مورد، سایت را نفوذناپذیر نمیکند. چیزی که میسازد، پایهای است که حملهٔ خودکارِ رایج را فیلتر میکند، هزینهٔ هر حادثه را میکاهد و بازیابی را ممکن نگه میدارد. امنیتِ ادامهدار محصول روتین است — آپدیت ماهانه، مرور دسترسیها، پایش نشانهها — که چارچوب کاملش در چکلیست ماهانهٔ امنیت وردپرس و در هاب امنیت و پشتیبانگیری ادامه مییابد؛ این دو متن با هم میخوانند و هیچکدام جای دیگری را نمیگیرد.
در سطح سوئیت هم همین فلسفه اجرا شده است: امنیت سازمانی سوئیت با امضای HMAC-SHA256، رمزنگاری AES-256 و بیش از ۹۰۰ تست خودکار بسته شده، چون به تجربهٔ ما امنیتِ قابلاتکا از قفلهای پایه + پایش خودکار ساخته میشود، نه از یک دیوار واحد. اگر پیش از انتشار میخواهید بدانید قابلیتهای پلتفرم در کدام لایه به کار شما میآید، قابلیتهای پلتفرم فهرست کامل را نشان میدهد؛ و فراخوان پایین همین متن، مسیر دیدنِ عملی آن است.
رصد ما، رشد شما.
سؤالات پرتکرار
این چکلیست را باید دقیقاً کی اجرا کنم؟
در روز صفر — بین نصب وردپرس و انتشار عمومی سایت. اگر سایت تازه منتشر شده، همان هفتهٔ اول با یک پنجرهٔ نگهداری اعلامشده اجرا کنید؛ هر چه دیرتر، هزینهٔ اصلاح بیشتر.
اگر سایت از قبل لایو است و پایهاش قفل نشده چه کنم؟
چهارده مورد را در سه پنجرهٔ نگهداری کوتاه اجرا کنید: اول بکاپ و پایش (کمریسکترین)، بعد بستر و هسته، در پایان دسترسیها. سایتِ بدون شبکهٔ بکاپ نباید هیچ تغییری را اولتر ببیند.
افزونهٔ امنیتی معتبر، جای این چکلیست را نمیگیرد؟
نمیگیرد؛ افزونه بخشی از باند دسترسی و پایش را مکانیکی میکند اما بستر (هاست، PHP، مجوزها) و تصمیمهای سازمانی مثل مالکیت حسابها بیرون از افزونه میمانند. افزونه بدون پایه، سپری روی دیوار ترکخورده است.
از چهارده مورد، چند مورد واقعاً به افزونه نیاز دارد؟
به تجربهٔ ما سه تا پنج مورد — ورود دومرحلهای، محدودسازی تلاش ورود، ثبت لاگ و اسکن زمانبندیشده. باقی موارد تنظیم هاست، فایل پیکربندی و تصمیم استاندارد است؛ با افزونه هم انجامپذیر است اما افزونهمحور نیست.
فرق این چکلیست با چکلیست ماهانهٔ امنیت چیست؟
این متن روز صفر را میبندد: قفلهای یکبارهٔ پایه. چکلیست ماهانه همان ردیفها را بعد از انتشار، هر ماه با ترتیب ثابت و ثبت نتیجه تکرار میکند؛ بدون پایهٔ روز صفر، روتین ماهانه عملاً آتشنشانی دائمی میشود.