امنیت سایت شرکتی با نصب یک افزونه یا خرید SSL کامل نمی‌شود. مهاجم می‌تواند از رمز تکراری مدیر، افزونه قدیمی، دسترسی پیمانکار سابق، کد آسیب‌پذیر، تنظیم اشتباه سرور یا حساب دامنه وارد شود. بنابراین امنیت باید هم‌زمان افراد، فرایند، کد، زیرساخت و سرویسهای متصل را پوشش دهد.
هدف نیز ساختن «سایت غیرقابل هک» نیست؛ چنین تضمینی واقع‌بینانه نیست. هدف کاهش احتمال نفوذ، محدود کردن دامنه آسیب، کشف سریع رخداد و بازیابی مطمئن است. در این راهنما اقدامات مدیریتی و فنی، نکات وردپرس و سایت اختصاصی و شرایط خاص کسب‌وکارهای ایرانی را مرحله‌به‌مرحله بررسی می‌کنیم.
امنیت یک پروژه یک‌باره نیست. هر تغییر کد، کارمند، افزونه، سرویس، رمز یا زیرساخت می‌تواند سطح ریسک سایت را تغییر دهد.
از شناخت دارایی و ریسک شروع کنید
قبل از خرید ابزار، فهرست کنید چه چیزی باید محافظت شود: دامنه، کد، اطلاعات مشتری، سفارش، فایل خصوصی، پنل مدیریت، ایمیل سازمانی، درگاه پرداخت، پیامک، مخزن کد، سرور و بکاپ. برای هر دارایی یک مالک و سطح اهمیت تعیین کنید.
سه سؤال ساده مسیر امنیت را روشن میکند:
- اگر این بخش از دسترس خارج شود چه اثری بر کسب‌وکار دارد؟
- اگر داده آن افشا یا تغییر کند چه آسیبی ایجاد می‌شود؟
- چه کسانی و از چه مسیری به آن دسترسی دارند؟
فروشگاه، پرتال مشتری و سامانه دارای داده حساس به کنترل‌های بیشتری نسبت به سایت معرفی کم‌تغییر نیاز دارند. بودجه باید ابتدا روی ریسک‌های بزرگ‌تر خرج شود.
مسئول امنیت را مشخص کنید
وقتی همه «مسئول امنیت» هستند، معمولاً هیچ‌کس مالک واقعی کار نیست. یک فرد باید مسئول هماهنگی بهروزرسانی، مرور دسترسی، بکاپ، هشدارها و واکنش به رخداد باشد. مسئولیت هاست، توسعه‌دهنده، شرکت پشتیبانی و مالک سایت نیز جدا نوشته شود.
اگر نگهداری را برون‌سپاری می‌کنید، دامنه خدمت، SLA، روش گزارش و مسئول بکاپ را روشن کنید. صفحه خدمات پشتیبانی سایت به شناخت وظایف قابل واگذاری کمک میکند.
رمزهای عبور را اصولی مدیریت کنید
- برای هر حساب رمز طولانی و یکتا بسازید.
- رمز را در Password Manager معتبر نگه دارید، نه فایل Excel، چت یا مرورگر مشترک.
- رمز یک حساب را برای هاست، ایمیل، وردپرس و شبکه اجتماعی تکرار نکنید.
- حساب مشترک مدیر نسازید؛ هر فرد حساب جدا داشته باشد.
- رمز را فقط هنگام احتمال افشا، خروج همکار یا رخداد امنیتی تغییر دهید. تغییر دوره‌ای بدون دلیل می‌تواند به انتخاب رمز ضعیف منجر شود.
- بازیابی رمز را به ایمیل و شماره‌ای وصل کنید که خودش امن و تحت کنترل سازمان است.
- کد بازیابی و Emergency Access را در محل جدا و امن نگه دارید.
مهمترین حساب معمولاً ایمیل اصلی است، چون بازیابی دیگر سرویس‌ها از آن انجام می‌شود. محافظت از ایمیل، دامنه و Password Manager باید اولویت بالاتری داشته باشد.
2FA و MFA را کجا فعال کنیم؟
احراز هویت دومرحله‌ای یا 2FA باعث می‌شود دانستن رمز به‌تنهایی برای ورود کافی نباشد. آن را دست‌کم برای ایمیل سازمانی، پنل هاست، ثبت‌کننده دامنه، CDN، مخزن کد، Cloud، پنل مدیریت سایت، درگاه و سامانه پیامک فعال کنید.
در صورت پشتیبانی سرویس، Passkey یا کلید امنیتی سختافزاری در برابر فیشینگ مقاومتر از پیامک است. برنامه تولید کد یک‌بارمصرف نیز معمولاً انتخاب مناسبی است. پیامک بهتر از نبود عامل دوم است، اما به شماره، اپراتور و امنیت فرایند تعویض سیم‌کارت وابسته است.
اصل حداقل دسترسی را اجرا کنید
هر کاربر فقط به چیزی دسترسی داشته باشد که برای کارش لازم است. نویسنده سایت به نصب افزونه نیاز ندارد و شرکت محتوا نباید به سرور Production دسترسی دائمی داشته باشد. دسترسی موقت پس از پایان کار باید خودکار یا طبق چک‌لیست لغو شود.
- نقش‌ها و Permissionها را بر اساس وظیفه تعریف کنید.
- حساب مدیر را برای کار روزمره استفاده نکنید.
- هر سه ماه فهرست کاربران، API Key، SSH Key و Tokenها را مرور کنید.
- خروج کارمند یا پیمانکار را به فرایند لغو دسترسی متصل کنید.
- فعالیت‌های حساس مانند تغییر نقش، Export داده و تنظیم پرداخت را Log کنید.
- برای عملیات بسیار حساس تأیید دوباره یا اصل چهار چشم در نظر بگیرید.
دامنه، DNS و ایمیل سازمانی را امن کنید
تصاحب دامنه می‌تواند کل سایت و ایمیل را از کنترل خارج کند. حساب ثبت‌کننده باید متعلق به سازمان باشد، 2FA داشته باشد و ایمیل بازیابی آن به شخص یا پیمانکار وابسته نباشد. قفل انتقال دامنه، هشدار تغییر DNS و تمدید چندمرحله‌ای را فعال کنید.
برای ایمیل، SPF، DKIM و DMARC را متناسب با سرویس تنظیم کنید تا جعل فرستنده دشوارتر شود. گزارش‌های DMARC باید مرور شوند. حسابهای Forwarding، App Password و اتصال‌های OAuth ناشناس نیز بررسی شوند.
HTTPS لازم است، اما کافی نیست
TLS ارتباط مرورگر و سایت را رمزگذاری میکند و از شنود ساده جلوگیری میکند. همه صفحات باید از HTTPS استفاده کنند و HTTP به HTTPS هدایت شود. گواهی معتبر، تمدید خودکار، تنظیم امن Protocolها و Cookieهای Secure لازم‌اند.
وجود قفل مرورگر به معنی سالم بودن کد یا قابل اعتماد بودن مالک سایت نیست. سایت فیشینگ هم می‌تواند HTTPS داشته باشد. امنیت ارتباط فقط یک لایه است.
اصول کدنویسی امن برای سایت اختصاصی
اعتبارسنجی ورودی و Encoding خروجی
ورودی کاربر، فایل، Header، API و داده سرویس ثالث را غیرقابل اعتماد فرض کنید. نوع، طول، قالب و محدوده مقدار را در سمت سرور کنترل کنید. برای نمایش داده در HTML، JavaScript، URL یا SQL از Encoding متناسب با همان Context استفاده شود.
دسترسی به دیتابیس
Query را با Parameter Binding یا ORM معتبر بسازید و داده کاربر را به رشته SQL نچسبانید. حساب دیتابیس فقط مجوز لازم داشته باشد. دیتابیس عمومی نباشد و دسترسی مدیریتی آن محدود و ثبت شود.
Authentication و Authorization
ورود کاربر با مجوز دسترسی فرق دارد. در هر درخواست حساس، مالکیت منبع و نقش کاربر در سمت سرور بررسی شود. مخفی کردن دکمه در Frontend مانع دسترسی مستقیم به API نیست. برای عملیات حساس Re-authentication و MFA در نظر بگیرید.
نگهداری امن رمز کاربران
رمز نباید Plain Text یا با رمزنگاری قابل بازگشت ذخیره شود. از قابلیت استاندارد Framework برای Hash تطبیقی مانند Argon2id، bcrypt یا PBKDF2 استفاده کنید و تنظیمات را با توصیه روز کتابخانه هماهنگ نگه دارید. الگوریتم اختصاصی نسازید.
Session و Cookie
شناسه Session طولانی و تصادفی باشد و پس از ورود یا تغییر سطح دسترسی Rotate شود. Cookie حساس با Secure، HttpOnly و SameSite مناسب تنظیم شود. Logout باید Session سمت سرور را باطل کند. Token حساس را بدون دلیل در Local Storage نگه ندارید.
CSRF، XSS و تزریق
برای درخواست تغییردهنده وضعیت از محافظت CSRF استفاده کنید. داده خروجی را درست Encode و در صورت نیاز HTML را با Allowlist پاک‌سازی کنید. Content Security Policy می‌تواند لایه کمکی باشد، اما جای رفع XSS را نمی‌گیرد.
آپلود فایل
پسوند و Content-Type به‌تنهایی قابل اعتماد نیست. نوع واقعی، اندازه و نام فایل را کنترل کنید، نام تازه بسازید و Upload را بیرون مسیر اجرای کد نگه دارید. فایل خصوصی باید با مجوز برنامه ارائه شود، نه URL قابل حدس.
خطا و اطلاعات حساس
Stack Trace، Query، مسیر داخلی و Secret را به کاربر نمایش ندهید. پیام عمومی به کاربر و جزئیات کافی در Log امن ثبت شود. Debug Mode در Production خاموش باشد.
Secret Management
رمز دیتابیس، API Key و Private Key داخل Git، فایل عمومی یا گروه پیام‌رسان قرار نگیرد. از Secret Manager یا متغیر محیطی با کنترل دسترسی استفاده کنید. Secret باید Owner، تاریخ ایجاد، روش Rotate و مسیر لغو داشته باشد.
چرخه توسعه امن ایجاد کنید
- پیش از ساخت قابلیت، Threat Modeling ساده انجام دهید.
- معیار امنیت را کنار معیار عملکرد در Definition of Done قرار دهید.
- Code Review برای تغییر حساس اجباری باشد.
- Dependency، Secret و آسیبپذیری شناخته‌شده در Pipeline اسکن شود.
- تست Authorization، ورودی و مسیرهای سوءاستفاده به تست خودکار اضافه شود.
- Build قابل تکرار و Artifact امضاشده یا قابل تطبیق نگه دارید.
- Deploy به Production فقط از مسیر کنترل‌شده انجام شود.
- پس از انتشار، Log و شاخص خطا برای نشانه غیرعادی بررسی شود.
ابزار اسکن جای Review و طراحی امن را نمی‌گیرد. یافته‌ها باید بررسی، اولویت‌بندی و تا رفع نهایی پیگیری شوند.
Dependency و زنجیره تأمین را کنترل کنید
هر پکیج، افزونه و سرویس خارجی سطح حمله را بزرگ میکند. فقط اجزای ضروری را نگه دارید و منبع، License، Maintainer و سابقه بهروزرسانی را بررسی کنید. فایل Lock را Commit کنید و تغییر ناگهانی Dependency را Review کنید.
نسخه آسیب‌پذیر را سریع وصله کنید، اما بهروزرسانی بزرگ را ابتدا در Staging آزمایش کنید. اجزای رهاشده باید جایگزین یا حذف شوند. دانلود نسخه کرک‌شده قالب و افزونه، ریسک کد دست‌کاری‌شده را بالا می‌برد.
زیرساخت و سرور را سخت‌سازی کنید
- سیستم‌عامل، وب‌سرور، Runtime و دیتابیس پشتیبانی‌شده و به‌روز باشند.
- پورت و سرویس غیرضروری بسته یا حذف شود.
- ورود مدیریتی با SSH Key و دسترسی شبکه محدود انجام شود.
- کاربر برنامه Root نباشد و Permission فایل حداقلی باشد.
- Production، Staging و محیط توسعه از هم جدا باشند.
- دیتابیس و پنل مدیریت مستقیماً برای همه اینترنت باز نباشند.
- لاگ سیستم به محل جدا و مقاوم در برابر دست‌کاری ارسال شود.
- ظرفیت، فایل، Process و ارتباط خروجی غیرعادی مانیتور شود.
- Configuration به‌صورت نسخه‌پذیر و قابل بازبینی نگهداری شود.
WAF، CDN و محافظت DDoS را درست به‌کار ببرید
WAF می‌تواند بخشی از درخواست‌های مخرب شناخته‌شده را متوقف کند و Rate Limit از سوءاستفاده خودکار کم کند. CDN و محافظت DDoS نیز دسترس‌پذیری را بهتر می‌کنند. اما تنظیم اشتباه ممکن است کاربر واقعی یا موتور جست‌وجو را مسدود کند.
Origin را تا حد امکان فقط برای مسیرهای مورد اعتماد قابل دسترسی کنید تا مهاجم WAF را دور نزند. Ruleها، False Positive و تغییرات Provider باید ماهانه مرور شوند.
افزایش امنیت سایت وردپرسی
- WordPress، قالب و افزونه‌ها را از منبع معتبر و به‌روز نگه دارید.
- افزونه و قالب غیرفعال و بدون استفاده را حذف کنید.
- برای هر مدیر حساب جدا و 2FA فعال کنید.
- تعداد Administratorها را حداقل نگه دارید.
- ویرایش فایل از Dashboard را در صورت سازگاری فرایند غیرفعال کنید.
- Permission فایل، wp-config.php و مسیر Upload را بررسی کنید.
- تغییر فایل، ایجاد مدیر، Login ناموفق و نصب افزونه را Log کنید.
- Login و XML-RPC را متناسب با نیاز Rate Limit یا محدود کنید.
- بکاپ فایل و دیتابیس را خارج از هاست نگه دارید و Restore را آزمایش کنید.
- محیط مدیران سایت و لپ‌تاپ آن‌ها را نیز امن و به‌روز نگه دارید.
تغییر URL ورود یا Prefix دیتابیس می‌تواند نویز Bot را کم کند، اما کنترل اصلی امنیت نیست. بهروزرسانی، حداقل دسترسی، 2FA، بکاپ و مانیتورینگ ارزش بیشتری دارند.
بکاپ امن و قابل بازیابی بسازید
بکاپ باید فایل، دیتابیس و تنظیمات لازم برای بازگشت را پوشش دهد. حداقل یک نسخه در حساب یا زیرساخت جدا نگهداری شود تا مهاجم با دسترسی به سرور همه نسخه‌ها را حذف نکند. دسترسی، رمزنگاری و مدت نگهداری را تعریف کنید.
RPO مشخص میکند چه مقدار داده را می‌توانید از دست بدهید و RTO زمان هدف بازیابی را نشان می‌دهد. آزمون Restore باید دوره‌ای انجام شود. وجود فایل Backup بدون آزمون، تضمین بازیابی نیست.
Logging و مانیتورینگ را قابل اقدام کنید
ورود موفق و ناموفق، تغییر نقش، Export داده، تغییر تنظیمات، Deploy، خطای سرور، WAF و فعالیت دیتابیس حساس را ثبت کنید. Log نباید رمز، Token یا اطلاعات بیش از نیاز کاربر را نگه دارد.
هشدار برای مواردی مانند ورود مدیر از الگوی غیرعادی، ایجاد کاربر جدید، افزایش ۵xx، تغییر فایل، جهش پیامک و مصرف منابع تنظیم شود. زمان سیستم‌ها همگام و نگهداری Log با ریسک و نیاز کسب‌وکار متناسب باشد.
آزمون امنیت را مرحله‌ای انجام دهید
- اسکن خودکار Dependency و Configuration در هر تغییر
- اسکن آسیبپذیری دوره‌ای و پس از تغییر بزرگ
- Review دستی بخش‌های Authentication و Authorization
- آزمون نفوذ با مجوز، Scope، زمان و Rules of Engagement روشن
- Retest پس از رفع یافته مهم
- تمرین واکنش به رخداد و بازیابی بکاپ
آزمون نفوذ بدون هماهنگی می‌تواند سرویس را مختل یا از نظر حقوقی مسئله‌ساز شود. گزارش خوب باید مدرک، شدت، اثر، راه اصلاح و نتیجه Retest داشته باشد.
کارکنان و پیمانکاران را فراموش نکنید
فیشینگ ایمیل، فایل آلوده، درخواست جعلی مدیر و سرقت Session می‌تواند کنترل‌های فنی را دور بزند. آموزش کوتاه و تکرارشونده، کانال گزارش پیام مشکوک و تأیید دوم برای تغییر اطلاعات مالی ضروری است.
در قرارداد پیمانکار، محرمانگی، حد دسترسی، دستگاه مجاز، استفاده از نیروی فرعی، گزارش رخداد و تحویل پایان همکاری نوشته شود. دسترسی دائمی برای کاری که ماهی یک‌بار انجام می‌شود منطقی نیست.
نکات مهم برای امنیت سایت در ایران
- مالکیت حسابها: دامنه ir، دامنه بین‌المللی، هاست، CDN و سرویس پیامک تحت کنترل سازمان باشند، نه حساب شخصی مجری.
- پایش چندنقطه‌ای: دسترسی و Redirect از شبکه داخل ایران و یک نقطه خارج ایران سنجیده شود.
- سرویس جایگزین: برای پیامک، ایمیل، نقشه، CDN یا API حیاتی که ممکن است محدود شود، برنامه جایگزین داشته باشید.
- درگاه پرداخت: تغییر Merchant، Callback، IP مجاز و مغایرت تراکنش پایش شود.
- OTP پیامکی: Rate Limit، انقضا، تعداد تلاش و جلوگیری از مصرف انبوه اعتبار اجرا شود.
- بکاپ مستقل: نسخه‌ها فقط در همان دیتاسنتر یا حساب میزبان نباشند.
- تعطیلات و On-call: برای تعطیلات طولانی و کمپین پرتراکنش مسئول پاسخ مشخص باشد.
- تمدید ارزی: انقضای License و سرویس خارجی زودتر پایش و مسیر پرداخت قانونی یا جایگزین بررسی شود.
- اختلال را با حمله اشتباه نگیرید: مشکل مسیر اینترنت، DNS، دیتاسنتر و کد را با داده جدا کنید.
برنامه واکنش به رخداد داشته باشید
قبل از نفوذ تعیین کنید چه کسی تصمیم می‌گیرد، چگونه سایت مهار می‌شود، شواهد کجا نگهداری می‌شوند و با چه کسی تماس می‌گیرید. فهرست تماس هاست، ثبت‌کننده دامنه، درگاه، پیامک، تیم فنی، حقوقی و مدیر تصمیم‌گیر در دسترس باشد.
اگر نشانه مشکوکی دیدید، راهنمای مهمترین نشانه‌های هک شدن سایت ترتیب ثبت، مهار، امنسازی دسترسی و بازیابی را توضیح می‌دهد.
نقشه ۳۰ روزه افزایش امنیت
| بازه | اولویت‌ها |
|---|---|
| روز ۱ تا ۳ | فهرست دارایی، امنسازی ایمیل و دامنه، 2FA مدیران، حذف دسترسی قدیمی و تأیید بکاپ |
| روز ۴ تا ۷ | بهروزرسانی حیاتی، بررسی SSL و DNS، بستن سرویس غیرضروری و فعال کردن مانیتورینگ |
| هفته دوم | مرور نقش‌ها، Secretها، Dependencyها، تنظیم WAF و آزمون Restore |
| هفته سوم | Code Review بخش‌های حساس، اسکن امنیت، اصلاح یافته‌های مهم و Logging |
| هفته چهارم | تمرین رخداد، مستندسازی، آموزش کارکنان و تعیین برنامه ماهانه و فصلی |
شاخص‌های ساده برای سنجش بهبود
- درصد حسابهای حساس دارای MFA
- تعداد حساب و Token بدون مالک
- میانگین زمان نصب وصله حیاتی پس از تأیید
- درصد بکاپ‌های موفق و نتیجه آزمون Restore
- زمان کشف و مهار رخداد
- تعداد Dependency و افزونه بدون استفاده
- یافته‌های امنیتی باز بر اساس شدت و عمر
- درصد تغییرات Production دارای Review و ثبت Deploy
عدد باید به اقدام منجر شود. زیاد شدن هشدارها لزوماً به معنی امنیت بهتر نیست؛ هشدار دقیق و پاسخ به‌موقع مهم‌تر است.
اشتباهات رایج در افزایش امنیت سایت
- اعتماد کامل به یک افزونه امنیتی یا WAF
- تغییر ظاهری URLها به‌جای رفع آسیبپذیری
- فعال کردن 2FA فقط برای وردپرس و فراموش کردن ایمیل و دامنه
- ذخیره رمز و Secret در چت، Git یا فایل مشترک
- بهروزرسانی مستقیم Production بدون بکاپ و آزمون
- نگهداری همه بکاپ‌ها روی همان سرور
- دادن دسترسی Administrator به همه همکاران
- خرید ابزار بدون تعیین مسئول بررسی هشدار
- پنهان کردن رخداد و تکرار همان مسیر نفوذ
جمع‌بندی
برای افزایش امنیت سایت شرکتی باید چند لایه مستقل بسازید: حساب امن و 2FA، حداقل دسترسی، دامنه و ایمیل محافظت‌شده، کدنویسی امن، Dependency به‌روز، سرور سخت‌سازی‌شده، WAF، بکاپ مستقل، Logging و برنامه واکنش. وردپرس و سایت اختصاصی جزئیات متفاوتی دارند، اما اصول پایه یکسان‌اند.
از دارایی‌های حیاتی و حسابهای اصلی شروع کنید، سپس ریسک‌های کد و زیرساخت را برطرف کنید و امنیت را وارد نگهداری ماهانه کنید. در شرایط ایران، کنترل مالکیت حساب، پایش از چند شبکه، درگاه و پیامک، سرویس جایگزین و بکاپ خارج از زیرساخت اصلی اهمیت ویژه‌ای دارد.
