امنیت هاست اشتراکی؛ ریسک‌ها، معیار انتخاب و زمان مهاجرت

هاست اشتراکی ناامن نیست؛ هاست اشتراکیِ بدون Isolation قابل اثبات، Patch منظم، Backup مستقل و پاسخ‌گویی شفاف ناامن است. از طرف دیگر، VPS هم خودبه‌خود امن‌تر نمی‌شود: اگر Patch سیستم‌عامل، Firewall، Log و Backup بدون Owner بماند، Root access فقط سطح مسئولیت و خطا را بیشتر می‌کند.

این راهنما کمک می‌کند ریسک امنیت هاست اشتراکی را واقعی بسنجید، مسئولیت میزبان و صاحب سایت را جدا کنید، یک سرویس را با سؤال و PoC انتخاب کنید و زمان مهاجرت به Managed WordPress، VPS یا معماری اختصاصی را تشخیص دهید.

خلاصه تصمیم: آیا هاست اشتراکی برای شما مناسب است؟

ارزان‌بودن نباید تنها معیار باشد، اما گران‌بودن نیز Evidence امنیتی نیست. مناسب‌ترین سرویس، نیاز شما را با کمترین Complexity عملیاتی و مسئولیت‌های روشن پوشش می‌دهد.

هاست اشتراکی چیست؟

در Shared hosting چند Account از Host فیزیکی، سیستم‌عامل، Network و بخشی از Serviceهای مشترک استفاده می‌کنند. Provider معمولاً Web server، PHP، Database service، Control panel، Patch سیستم و Resource limit را اداره می‌کند؛ شما Application، User، Plugin، Content و Credential خود را مدیریت می‌کنید.

اشتراک منابع الزاماً به معنی اشتراک دسترسی نیست. معماری سالم باید Tenantها را با User، Permission، Process، Filesystem و Resource control از هم جدا کند. اما نوع و قدرت این جداسازی در همه میزبان‌ها یکسان نیست و از نام Plan قابل تشخیص نیست.

VPS هم منابع فیزیکی مشترک دارد

VPS معمولاً با Hypervisor یا Virtualization از مهمان‌های دیگر جدا می‌شود و کنترل بیشتری می‌دهد، اما همچنان ممکن است CPU، Storage یا Network فیزیکی مشترک باشد. تفاوت اصلی برای شما، Boundary و Responsibility است: روی VPS اغلب Patch، SSH، Firewall، Package، Backup و Monitoring بر عهده تیم شماست.

سه نوع «همسایه» را از هم جدا کنید

Tenant دیگر روی همان Host

اگر Isolation میزبان شکست بخورد یا Kernel/Control panel آسیب‌پذیر باشد، رخداد یک Tenant ممکن است Boundary را تهدید کند. این ریسک زیرساختی باید با Isolation، Patch، Detection و Incident response میزبان کنترل شود.

سایت دیگر داخل همان Hosting account

این مورد بسیار مهم‌تر و رایج‌تر است. چند WordPress زیر یک cPanel/DirectAdmin account اغلب File owner و Credential domain مشترک دارند. نفوذ به یک Plugin می‌تواند فایل سایت‌های دیگر همان Account را تغییر دهد؛ Cage یا Isolation میان Customerها لزوماً داخل Account شما مرز نمی‌سازد.

همسایه پرمصرف

یک سایت می‌تواند CPU، I/O، Process، Connection یا Mail reputation را مصرف کند. Resource limit درست باید اثر را مهار کند. این مسئله بیشتر Availability و Performance است، اما قطعی و Timeout می‌تواند Login، Backup یا Update امنیتی را نیز مختل کند.

ریسک‌های اصلی امنیت هاست اشتراکی

آیا IP مشترک به سئو آسیب می‌زند؟

صرف استفاده چند سایت از یک IP، جریمه SEO عمومی ایجاد نمی‌کند؛ معماری‌های CDN و Shared hosting به‌طور طبیعی IP مشترک دارند. ریسک واقعی این‌هاست:

• قطعی و 5xx مکرر که Crawl و تجربه کاربر را خراب کند.
• هک، Spam page یا Redirect مخرب در خود سایت شما.
• کندی ناشی از Resource contention.
• مشکل Email deliverability روی IP خروجی مشترک.
• Block شبکه یا Reputation در سرویس‌های ثالث خاص.

Shared IP را به‌عنوان شاخص کیفیت فنی بررسی کنید، نه عامل رتبه مستقل. برای Email تراکنشی بهتر است Reputation و Provider آن از Web hosting جدا و قابل مانیتور باشد.

مدل مسئولیت مشترک

راهنمای رسمی Hardening در WordPress نیز تأکید می‌کند میزبان زیرساخت را تا سطحی امن می‌کند، اما مالک سایت مسئول Application انتخابی است؛ همچنین توصیه می‌کند درباره تدابیر Shared server، نسخه‌های پایدار و Backup/Recovery از میزبان سؤال شود.

چک‌لیست ارزیابی میزبان پیش از خرید

Isolation و Account boundary

• هر Account با چه OS user و PHP process اجرا می‌شود؟
• Filesystem و Process tenantها چگونه جدا می‌شوند؟
• Resource limit برای CPU، RAM، I/O، Entry process و DB connection چیست؟
• چند سایت داخل یک Account مرز مستقل دارند یا خیر؟
• رخداد Escape/Isolation failure چگونه Detect و Communicate می‌شود؟

نام فناوری مانند CloudLinux/CageFS مفید است، اما کافی نیست. Version، Config، Operational monitoring و پاسخ Incident مهم‌اند. از فروشنده فقط Logo نخواهید؛ Boundary و Scope را بخواهید.

Patch و Lifecycle

• نسخه‌های PHP، Database، Web server و Control panel چیست؟
• برای Critical vulnerability چه Patch SLAای دارند؟
• آیا Live patch یا Maintenance window وجود دارد؟
• End-of-life version چگونه و چه زمانی حذف می‌شود؟
• اگر Application شما با Version جدید ناسازگار باشد، مسیر Staging چیست؟

Identity و Control panel

• MFA برای Panel، Support account و Billing وجود دارد؟
• Recovery با چه Evidenceای انجام می‌شود؟
• Session و Login history قابل مشاهده است؟
• Sub-account و Least privilege برای همکار فراهم است؟
• Support agent تحت چه شرایطی وارد Account می‌شود و Audit آن کجاست؟

در cPanel، مستند رسمی Two-Factor Authentication نشان می‌دهد 2FA یک قابلیت مشخص Control panel است؛ از میزبان بپرسید فعال است، اجباری می‌شود یا فقط روی برخی Planها ارائه می‌شود.

Backup و Disaster Recovery

• چه چیزهایی Backup می‌شوند: Files، Database، Email، DNS یا کل Account؟
• Frequency، Retention، Encryption و Failure domain چیست؟
• Backup تحت همان Credential قابل حذف است؟
• Restore self-service یا Ticket است و SLA آن چقدر است؟
• Full export بدون محدودیت و هزینه پنهان ممکن است؟
• آخرین Restore test و نرخ موفقیت چیست؟

نسخه میزبان را تنها Copy ندانید. راهنمای بازیابی فاجعه و Backup سایت معماری مستقل و Drill را توضیح می‌دهد.

Log، Detection و Incident response

• Raw access/error/PHP log در دسترس است؟ Retention چند روز است؟
• File change، Malware و Abuse چگونه Detect می‌شود؟
• Alert به شما می‌رسد یا فقط Account Suspend می‌شود؟
• در رخداد Cross-account چه Timeline و Notificationی دارید؟
• Evidence چگونه حفظ و Export می‌شود؟
• کانال Escalation خارج Ticket عمومی چیست؟

DDoS، WAF و Origin

عبارت «Anti-DDoS» را با Capacity، Layer، Threshold، Null-route policy و محدودیت Plan دقیق کنید. WAF باید Mode، Rule set، Tuning و Log داشته باشد. برای معماری لبه و مبدا از راهنمای فایروال سایت و WAF استفاده کنید.

Baseline امنیتی صاحب سایت

Identity

• رمز منحصربه‌فرد برای Hosting، Registrar، DNS، Email و WordPress
• MFA برای Panel، Admin، Billing و Support
• حداقل دو Authenticator و Recovery code آفلاین
• حذف Account قدیمی و اشتراک‌ندادن Login
• Review دوره‌ای Session، API token و SFTP user

روش Rollout و Break-glass در راهنمای MFA پنل مدیریت آمده است.

دسترسی فایل و انتقال امن

• از SFTP/SSH به‌جای FTP بدون رمزنگاری استفاده کنید.
• برای هر همکار User جدا و مسیر محدود بسازید.
• Permission را بر نیاز واقعی تنظیم کنید؛ ۷۷۷ راه‌حل عمومی نیست.
• Secret و Backup را در Web root عمومی نگذارید.
• File manager و SSH key بلااستفاده را حذف کنید.

Update و Supply chain

• Core، Plugin و Theme را از Source معتبر بگیرید.
• افزونه و قالب بلااستفاده را حذف کنید، نه فقط Disable.
• Vulnerability advisory و Changelog را دنبال کنید.
• Update را روی Staging تست و Rollback را آماده کنید.
• Plugin نال‌شده یا Package ناشناخته را وارد Production نکنید.

فرایند عملی در راهنمای به‌روزرسانی امن WordPress توضیح داده شده است.

جداسازی سایت‌های داخل Account

سایت مشتری، فروشگاه اصلی، Landing آزمایشی و WordPress قدیمی را فقط برای صرفه‌جویی زیر یک File owner جمع نکنید. بهترین Containment، Account جدا با Database user، SFTP user و Backup جداست. اگر Plan اجازه نمی‌دهد، Blast radius را بپذیرید یا Plan را تغییر دهید.

Database و Secret

• هر سایت Database و User جدا داشته باشد.
• Remote DB access فقط در صورت نیاز و محدود به Source مشخص باشد.
• Secret را در Repository یا Ticket عمومی قرار ندهید.
• پس از Incident، Password و Salt/API keyهای در معرض خطر را Rotate کنید.
• Privilege را کمینه کنید، اما Update schema را با Plan مدیریت کنید.

TLS

HTTPS مسیر کاربر تا Edge و Edge تا Origin را پوشش دهد. Renewal و Chain را بیرونی مانیتور کنید. مقاله انتخاب و تمدید گواهی SSL/TLS چک‌لیست کامل را ارائه می‌کند.

افزونه امنیتی چه کمکی می‌کند و چه چیزی را حل نمی‌کند؟

Plugin می‌تواند Login protection، MFA، File scan، Audit و برخی WAF ruleها را فراهم کند. اما نمی‌تواند Kernel، Isolation tenantها، Network، Storage، Control panel یا Patch میزبان را اصلاح کند. چند Plugin هم‌پوشان ممکن است Performance و عیب‌یابی را بدتر کند.

به‌جای نصب چند ابزار، Gap خود را مشخص و با PoC انتخاب کنید. مقایسه Wordfence، Sucuri، Kadence Security، AIOS و MalCare در راهنمای افزونه‌های امنیتی WordPress آمده است.

تغییر URL ورود دفاع اصلی نیست

پنهان‌کردن مسیر Login ممکن است Noise Bot را کم کند، اما Authentication را قوی نمی‌کند و API/XML-RPC/Recovery یا مسیرهای کشف دیگر باقی می‌مانند. دفاع اصلی شامل MFA، Password امن، Rate limit، Bot/WAF، Session management و Logging است. Security through obscurity فقط کنترل کمکی است.

Backup مستقل در هاست اشتراکی

Backup Plugin اگر روی همان Account بنویسد، در Account takeover یا Storage failure از بین می‌رود. حداقل یک Copy باید:

• خارج Hosting account باشد.
• Credential جدا و MFA داشته باشد.
• Encryption و Retention مشخص داشته باشد.
• Database و Files را سازگار نگه دارد.
• روی محیط دیگر Restore و تست شده باشد.
• بدون wp-admin آسیب‌دیده قابل دسترس باشد.

برای فروشگاه، RPO سفارش/پرداخت را جدا از Media/Content تعیین کنید. Snapshot روزانه ممکن است برای Product کافی و برای Transaction ناکافی باشد.

Monitoring در محیطی که Root ندارید

نبود Root به معنی نبود Observability نیست. حداقل این Signalها را جمع کنید:

• Uptime و Status code چند Endpoint از بیرون
• Latency و TTFB در Percentile
• 5xx، PHP fatal و Resource limit event
• Login/Admin action و File change
• Backup success و Restore age
• TLS expiry و DNS change
• Checkout، Callback و Synthetic transaction
• Email bounce و Queue

از میزبان Export یا API Log بخواهید و Signal برنامه را جدا نگه دارید. اگر Incident رخ دهد، راهنمای تشخیص و پاک‌سازی بدافزار برای Evidence، Containment و Rebuild کمک می‌کند.

سناریوهای آزمون امنیت هاست اشتراکی

هیچ تست نفوذ یا Load غیرمجاز روی Shared host اجرا نکنید. Rules of engagement و محدودیت Provider را کتبی بگیرید. PoC باید Production همسایه‌ها را تهدید نکند.

Scorecard انتخاب هاست اشتراکی

وزن‌ها را با کسب‌وکار عوض کنید. فروشگاه ممکن است Restore و Checkout را سنگین‌تر وزن دهد؛ سایت محتوایی شاید Support و Cost را. ابتدا Must-have gate تعیین کنید: نبود MFA یا Export کامل نباید با امتیاز قیمت جبران شود.

PoC دوهفته‌ای پیش از انتقال کامل

روز ۱ تا ۳: Setup و Baseline

• ساخت Account، MFA، SFTP user و Database جدا
• نصب Staging با نسخه واقعی PHP/Plugin
• ثبت Limit، Header، Log و Baseline عملکرد

روز ۴ تا ۷: Backup و Security operations

• Backup کامل و Restore روی Subdomain ایزوله
• تست Expiry/TLS، File change و Login audit
• ارسال Ticket فنی و سنجش احراز هویت/زمان پاسخ

روز ۸ تا ۱۱: Compatibility و Performance

• Smoke test WordPress، Cron، REST، Email و Cache
• Checkout Sandbox/کم‌ریسک و Callback
• بررسی Resource event با روش مجاز Provider

روز ۱۲ تا ۱۴: Exit test و تصمیم

• Export Files/DB/DNS و Restore روی محیط دوم
• تکمیل Scorecard، Gap، هزینه پنهان و Owner
• Go/No-go با Plan مهاجرت و Rollback

چه زمانی از هاست اشتراکی مهاجرت کنیم؟

• Resource limit به‌طور پایدار روی تجربه یا فروش اثر دارد.
• نیاز به Module، Queue، Worker، Network policy یا Runtime سفارشی دارید.
• Log/Retention برای Incident و Compliance کافی نیست.
• RPO/RTO با Restore میزبان برآورده نمی‌شود.
• چند سایت حساس زیر یک Account Blast radius بزرگی ساخته‌اند.
• Provider Patch/Incident/Isolation را شفاف نمی‌کند.
• Traffic یا Jobهای Background با مدل Shared ناسازگار شده‌اند.
• نیاز به Private network، Dedicated database یا Secret manager دارید.
• هزینه Add-onها از Managed/VPS بیشتر شده است.

Shared، Managed WordPress، VPS یا Dedicated؟

Dedicated hardware آسیب‌پذیری Application را حل نمی‌کند؛ Managed label هم باید Scope و SLA داشته باشد. تصمیم خوب، Responsibility را با توان تیم هماهنگ می‌کند.

معیارهای خاص برای کسب‌وکار ایرانی

• دسترسی پایدار تیم به Panel، DNS و Backup از شبکه‌های مورد استفاده
• پشتیبانی فارسی و کانال Escalation در ساعات Incident
• روش پرداخت و خطر Suspend ناگهانی Account
• محل Datacenter، Latency کاربران و مسیر CDN
• ظرفیت و سیاست DDoS برای ترافیک داخلی/بین‌المللی
• امکان Export سریع بدون وابستگی به سرویس خارجی محدود
• Backup خارج Datacenter/Provider با مسیر Restore آزموده
• شفافیت تومان/ریال، تمدید، Add-on و هزینه Restore/Egress
• سازگاری Email/SMS/درگاه و دسترسی Callback

از توصیه نام‌محور دوری کنید؛ کیفیت Plan و تیم میزبان تغییر می‌کند. قرارداد، PoC و Evidence امروز از Review قدیمی ارزشمندتر است.

Runbook رخداد روی هاست اشتراکی

1. ثبت زمان و نشانه: Deface، Redirect، Malware، 5xx یا Account alert.
2. حفظ Evidence: Log، File timestamp، Header، Ticket و Snapshot قبل از تغییر.
3. Containment: Site آسیب‌دیده را جدا، Session/API key را Revoke و با میزبان Escalate کنید.
4. تعیین Scope: فقط یک Site، همه Siteهای Account یا Host-wide؟
5. Rotation: Panel، SFTP، DB، WordPress، Email، DNS و Secretهای مرتبط.
6. Clean rebuild: Core/Plugin/Theme از Source معتبر و Data بررسی‌شده.
7. Validation: Malware، User، Cron، DB، SEO، Checkout و Log.
8. بازگشت کنترل‌شده: WAF/Monitor فعال و Traffic مرحله‌ای.
9. Postmortem: Root cause، مسئولیت میزبان/شما، Gap و تصمیم Migration.

اگر میزبان Evidence را بدون اطلاع حذف، Account را فوراً Reimage یا فقط «فایل آلوده» را پاک می‌کند، Scope و Root cause ممکن است گم شود. از ابتدا فرایند Incident را در قرارداد/Plan بپرسید.

اشتباهات رایج

• فرض اینکه سایت هک‌شده همسایه حتماً به شما دسترسی دارد یا هرگز ندارد
• برابر دانستن Logo ابزار امنیتی با Isolation درست
• گذاشتن چند سایت نامرتبط زیر یک File owner
• استفاده از VPS بدون تیم Patch و Monitoring
• تغییر URL Login به‌عنوان دفاع اصلی
• اتکا به یک افزونه برای امنیت Host
• Backup روی همان Account و بدون Restore test
• دسترسی مشترک تیم و نبود MFA/Recovery
• Version منسوخ PHP برای سازگاری یک Plugin قدیمی
• نداشتن Raw log و شروع Forensic پس از حذف شواهد
• انتخاب صرفاً با قیمت، Uptime ادعایی یا Review نامعتبر
• مهاجرت بدون Exit test و Rollback

چک‌لیست نهایی

• Boundary میان Tenantها و Siteهای داخل Account روشن است.
• Version و Patch SLA زیرساخت ثبت شده است.
• MFA، User جدا و Recovery code فعال‌اند.
• Siteها، Databaseها و SFTP userهای حساس جدا هستند.
• Update و Supply chain WordPress کنترل می‌شود.
• Backup مستقل، Immutable/Offline و Restore drill دارید.
• Log، Alert و Incident escalation آزموده شده است.
• WAF/DDoS scope و Origin protection مشخص است.
• TLS، DNS، Email و Checkout مانیتور می‌شوند.
• Scorecard، PoC، Exit test و Migration trigger دارید.

پرسش‌های متداول امنیت هاست اشتراکی

۱. آیا هاست اشتراکی برای فروشگاه کوچک امن است؟

می‌تواند امن و اقتصادی باشد، اگر Account isolation، Patch، MFA، Backup مستقل، TLS، WAF و Support مناسب داشته باشد و Checkout/Restore در PoC تست شود. حجم تراکنش و RPO/RTO ممکن است زودتر از Traffic شما را به Plan مدیریت‌شده‌تر برساند.

۲. اگر سایت همسایه هک شود، سایت من هم هک می‌شود؟

نه لزوماً. Isolation سالم باید دسترسی Cross-account را متوقف کند. خطر بزرگ‌تر اغلب سایت‌های متعدد داخل Account خود شماست که File owner مشترک دارند. از میزبان درباره Boundary و رخدادهای Isolation سؤال و سایت‌های حساس را جدا کنید.

۳. VPS همیشه از هاست اشتراکی امن‌تر است؟

خیر. VPS کنترل و Boundary بیشتری می‌دهد، اما Patch سیستم‌عامل، SSH، Firewall، Backup و Monitoring را به شما منتقل می‌کند. VPS بدون تیم مسئول ممکن است از Shared مدیریت‌شده و درست‌پیکربندی‌شده پرریسک‌تر باشد.

۴. برای امنیت هاست اشتراکی چه افزونه‌ای نصب کنیم؟

اول Gap را مشخص کنید. Plugin می‌تواند MFA، Audit، Scan و Login defense بدهد، اما Isolation و Patch Host را حل نمی‌کند. یک گزینه را با Performance و PoC انتخاب کنید و از چند ابزار هم‌پوشان پرهیز کنید.

۵. مهم‌ترین سؤال از شرکت هاست چیست؟

یک سؤال کافی نیست. Isolation، Patch SLA، Backup failure domain، Restore time، Log retention، Incident notification، MFA و Export را با Evidence بخواهید. سپس Restore و Exit را در Trial واقعی امتحان کنید.

جمع‌بندی

امنیت هاست اشتراکی به کیفیت Isolation و عملیات میزبان و همچنین Hygiene برنامه شما بستگی دارد. Boundary سایت‌های داخل Account را کوچک کنید؛ MFA و Update را اجرا کنید؛ Backup مستقل و Log داشته باشید؛ و انتخاب سرویس را با Scorecard، PoC و Exit test انجام دهید. وقتی RPO/RTO، کنترل یا Compliance از مرز Shared عبور کرد، به Plan مدیریت‌شده‌تر مهاجرت کنید.

اگر نمی‌دانید Plan فعلی چه Failure domain و Blast radiusی دارد، از مشاوره امنیت و زیرساخت مایندیو برای Audit هاست، PoC و برنامه مهاجرت کمک بگیرید.

بازبینی فنی منابع: ۶ اوت ۲۰۲۶. ویژگی‌ها و Scope سرویس‌های Hosting متغیرند؛ مستند، قرارداد و Evidence همان Plan را مبنای تصمیم قرار دهید.