امنیت به مجموعه‌ای از تصمیم‌های کوچک و پیگیری مداوم وابسته است. نصب یک افزونه به‌تنهایی کافی نیست.
دسترسی‌ها را مرتب کنید
برای هر نفر حساب جداگانه بسازید و سطح دسترسی را بر اساس وظیفه تعیین کنید. رمزهای طولانی و یکتا انتخاب کنید و در صورت پشتیبانی، احراز هویت دومرحله‌ای را فعال کنید. حساب‌های بدون استفاده و افزونه‌های رهاشده را بررسی کنید. دسترسی مدیریتی را برای کارهای روزمره به همه اعضا ندهید.
به‌روزرسانی و آمادگی برای حادثه
نسخه‌های افزونه و قالب را از مسیر معتبر دریافت کنید. پیش از تغییرات مهم بکاپ داشته باشید و روش بازگشت را بدانید. گزارش ورودهای مشکوک و تغییر فایل‌ها می‌تواند برای بررسی رخداد مفید باشد. SSL ارتباط را رمزگذاری می‌کند، اما به معنی امن بودن کامل کد یا پاک بودن سایت از بدافزار نیست.
برای انتخاب یا تغییر زیرساخت، ابتدا وضعیت فعلی سایت را ثبت کنید. یک تغییر مشخص انجام دهید و سپس همان مسیرهای کاربری را دوباره آزمایش کنید. راهنماهای روناتا مبنای تصمیم‌گیری اولیه هستند و بررسی جزئیات هر سایت به داده واقعی نیاز دارد.
از سطح دسترسی و منابع نصب شروع کنید
برای هر فرد حساب مستقل بسازید. نویسنده محتوا نباید فقط برای انتشار مقاله دسترسی مدیر کامل داشته باشد. حساب همکاران جداشده را بازبینی کنید و دسترسی لازم برای پیمانکار را زمان‌دار نگه دارید. رمزهای مشترک تشخیص مسئول تغییر را سخت می‌کنند. احراز هویت دومرحله‌ای در صورت پشتیبانی ابزار، خطر استفاده از رمز لو‌رفته را کمتر می‌کند. نشست‌های قدیمی و Application Passwordهای بلااستفاده هم نیاز به بررسی دارند.
افزونه و قالب را از منبع قابل اعتماد دریافت کنید. وجود فایل نصب به معنی سالم بودن آن نیست. نرم‌افزار رهاشده، نسخه قدیمی و وابستگی بدون پشتیبانی را در فهرست نگهداری ثبت کنید. راهنمای سخت‌سازی وردپرس بر چند لایه حفاظت تاکید می‌کند. قبل از به‌روزرسانی مهم بکاپ داشته باشید و پس از آن مسیرهای اصلی را دوباره آزمایش کنید.
نشانه مشکوک را با شواهد بررسی کنید
ایجاد مدیر ناشناس، تغییر مقصد پرداخت، صفحات تبلیغاتی ناخواسته یا فایل PHP تازه در محل غیرمنتظره می‌توانند نیازمند بررسی باشند. یک نشانه به‌تنهایی علت یا دامنه آلودگی را ثابت نمی‌کند. زمان رخداد، فایل تغییرکرده، گزارش ورود و آخرین به‌روزرسانی را ثبت کنید. پیش از پاک‌سازی عجولانه، از وضعیت موجود نسخه حفاظت‌شده تهیه کنید تا شواهد لازم باقی بمانند.
اگر رخداد تایید شد، فقط حذف یک فایل کافی نیست. مسیر ورود، حساب‌های درگیر، نسخه‌های آسیب‌پذیر و دسترسی‌های باقی‌مانده باید بررسی شوند. تغییر رمز از دستگاه آلوده نیز می‌تواند دوباره همان اطلاعات را در معرض خطر بگذارد. پاک‌سازی، بستن راه ورود، تعویض دسترسی‌های درگیر و کنترل مجدد باید در یک برنامه هماهنگ انجام شوند. رمزهای تازه را در گزارش و تیکت عمومی ننویسید.
| موضوع | اقدام قابل بررسی |
|---|---|
| دسترسی | حساب مستقل و حداقل نقش لازم |
| نگهداری | فهرست نسخه‌ها و برنامه به‌روزرسانی |
| رخداد | ثبت زمان، تغییر فایل و گزارش ورود |
| بازیابی | نسخه مستقل و آزمون مقصد |
بکاپ و HTTPS را در جای درست ببینید
HTTPS ارتباط کاربر و سایت را رمزگذاری می‌کند و نشانه پاک بودن کد نیست. بکاپ هم حمله را متوقف نمی‌کند، اما در صورت سالم بودن و وجود مسیر بازیابی به بازگشت کمک می‌کند. نسخه‌ای که بعد از آلودگی تهیه شده ممکن است همان کد ناسالم را نگه دارد. به همین دلیل تاریخ رخداد و انتخاب نسخه سالم اهمیت دارند. راهنمای آزمون بکاپ این بخش را توضیح می‌دهد.
بعد از حادثه، صفحه اصلی را تنها معیار سلامت قرار ندهید. مسیرهای ورود، پرداخت، جست‌وجو و صفحات نمونه را بررسی کنید. خروجی ناشناس ممکن است فقط برای یک نوع کاربر یا خزنده نمایش داده شود. نتیجه بررسی را با محدوده و زمان آن ثبت کنید. ادعای امنیت کامل بدون تعریف دامنه آزمون، اطلاعات مفیدی برای تصمیم‌گیری نمی‌دهد. خدمات امنیت روناتا نیز بر همین تفکیک مسئولیت‌ها تکیه دارد.
